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

Peter Ekberg peda@axentia.se
Fri Oct 29 12:29:00 GMT 2004


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: install-nodeps-wrapper.patch
Type: application/octet-stream
Size: 1088 bytes
Desc: install-nodeps-wrapper.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20041029/8c1a00d8/attachment.obj>
-------------- next part --------------
--
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/


More information about the Cygwin mailing list