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