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

["Peter Ekberg" <peda at axentia dot se>]

Chuck wrote:
> 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.

I have this feeling also. The right thing to do would perhaps be
to not generate the wrapper in the first place, but that feels
more complex than your proposal below...

> 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...

Yup, clear enough, here's a patch that does as you outlined. It
even works :-). Thanks a bunch!

Only one Cygwin related problem left on my list for libtool-1.9f,
and that is linking a libtool shared lib against
/usr/lib/w32api/libdxguid.a which is not recognized as an import
lib (and probably isn't one either, I don't know). But it works
to link a dll against it if I make it pass the import check by
brute force...
Any hints for that one?

Cheers,
Peter

Attachment: install-nodeps-wrapper.patch
Description: install-nodeps-wrapper.patch

--
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/