[gnutls-dev] Guile problems in 1.7.12
ludo at gnu.org
Wed Jun 27 22:29:46 CEST 2007
Simon Josefsson <simon at josefsson.org> writes:
> ludo at chbouib.org (Ludovic Courtès) writes:
>> Simon Josefsson <simon at josefsson.org> writes:
>>> Still, the paths look right for me:
>> I think I got it (I hope so!):
>> * On my machine, Guile is installed in `/usr/local/'. Thus,
>> `GUILE_LDFLAGS' contain `-L /usr/local/lib', which leads Libtool to
>> add `/usr/local/lib' to RPATH.
>> * On your machine, Guile is installed in `/usr', so this does not
>> happen. And a `-L /usr/local/lib' to your Libtool link command-line
>> and you'll make the same observations as I do.
>> Unless I'm mistaken, the fix is to revert your `_LIBADD' patch and get
>> back to something along the lines of:
>> libXXX_LDFLAGS = $(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS) \
>> which makes sure that third-party libs (here, Guile) appear last.
> I didn't reply to this mail. Is this still a problem for you? I think
> it is more correct to use LIBADD rather than LDFLAGS here, so I'd like
> to debug why that doesn't work (and possibly report it as a bug) before
> making a change.
Well, I had forgotten about it too, but that's still valid. ;-)
To sum up: on my machine, Guile is installed in `/usr/local/lib', and so
is GnuTLS. The libtool link command-line looks like:
-L/usr/local/lib -lguile ... ../../lib/libgnutls.la ... \
The first `-L' leads libtool to add `/usr/local/lib' to the RPATH of
`libguile-gnutls.so'; the `../../lib/libgnutls.la' that follows leads
libtool to *append* `../../lib/.libs' to the RPATH. Consequently, the
`libgnutls.so' and `libguile-gnutls.so' that are picked up at run-time
are those from `/usr/local/lib', *not* the freshly-built ones.
The proposed fix (above) fixes the problem. That the `XXX_LIBS' vars
would better fit in `XXX_LIBADD' than in `XXX_LDFLAGS' really isn't an
issue: there's nothing in the libtool manual that forbids listing
libtool archives as part of LDFLAGS.
Is that clearer?
More information about the Gnutls-devel