This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avail for test: libtool-devel-1.9f_20041024-1, libltdl6-1.9f_20041024-1


Peter Ekberg wrote:
BTW, this is the command that generates the wrapper script
when it shouldn't:
/bin/sh ../libtool --mode=link --tag=CC gcc  -g -O2 -D_REENTRANT
-D_THREAD_SAFE -DDEBUG -g -Wall -Wpointer-arith -Wsign-compare
-Wstrict-prototypes -Wswitch -Wmissing-prototypes -Wreturn-type -Wshadow
-o xsendbut.exe  xsendbut.o -L/usr/X11R6/lib -lX11

I should perhaps note that xsendbut resides in a directory
where other executables are built that do indeed depend on
uninstalled libtool libs, if that is at all relevant?

I don't know. I don't THINK so, but...


On the off chance that you (or someone else) want to get
first hand experience of the problem, try libgii from cvs
available from:

cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/ggi login cvs -z3 -d:pserver:anonymous@cvs.sf.net:/cvsroot/ggi co ggi-core/libgii
cd ggi-core/libgii
./autogen.sh
./configure
make
make install


xsendbut is in the demos subdir.

Unfortunately my travel schedule won't allow me to look into this. It smells like there is a real problem in libtool somewhere, but darned if I know what it is.


It seems like a design decision was made, that IF in a given project there are ANY libtool libs, then libtool will "know" about it by having build_libtool_libs set to "yes". And thus, every executable is *assumed* to be linked against those libs, and will therefore have a wrapper and be linked against those shared libs.

Except in your case, you have ONE executable that is NOT linked against any shared libs...and the wrapper-check fails.

Maybe the right answer here is to change the check so that instead of

          # Check the variables that should have been set.
          test -z "$notinst_deplibs" && \
            func_fatal_error "invalid libtool wrapper script \`$wrapper'"

it checks for some other magic instead (which would need to be added to the "make a wrapper" code)

          # Check the variables that should have been set.
          test -z "$generated_by_libtool_version" && \
            func_fatal_error "invalid libtool wrapper script \`$wrapper'"

where the "make a wrapper" code ensures that the following assignment appears in the wrapper

ORIG> if test "$libtool_install_magic" = "%%%MAGIC variable%%%"; then
ORIG>  # install mode needs the following variables:
ORIG>  notinst_deplibs=....
NEW >  generated_by_libtool_version=$macro_version
ORIG> else


Our check wouldn't care about the actual VALUE of $generated_by_libtool_version -- only that it was, in fact, set to SOMETHING.



Can't flesh this out anymore right now, but you get the idea...


--
Chuck


-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]