[gnutls-dev] Guile problems in 1.7.12
Simon Josefsson
simon at josefsson.org
Fri Jun 29 16:21:08 CEST 2007
ludo at gnu.org (Ludovic Courtès) writes:
> Hi,
>
> 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) \
>>> $(GUILE_LDFLAGS)
>>>
>>> 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 ... \
> -o libguile-gnutls.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?
Thanks. I've now built installed guile-1.8.1 locally and was able to
reproduce the problem.
I re-read the automake manual on this, and it says:
`maude_LIBADD'
Extra objects can be added to a _library_ using the `_LIBADD'
variable. For instance, this should be used for objects
determined by `configure' (*note A Library::).
In the case of libtool libraries, `maude_LIBADD' can also refer to
other libtool libraries.
`maude_LDADD'
Extra objects (`*.$(OBJEXT)') and libraries (`*.a', `*.la') can be
added to a _program_ by listing them in the `_LDADD' variable.
For instance, this should be used for objects determined by
`configure' (*note Linking::).
`_LDADD' and `_LIBADD' are inappropriate for passing
program-specific linker flags (except for `-l', `-L', `-dlopen'
and `-dlpreopen'). Use the `_LDFLAGS' variable for this purpose.
For instance, if your `configure.ac' uses `AC_PATH_XTRA', you
could link your program against the X libraries like so:
maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)
We recommend that you use `-l' and `-L' only when referring to
third-party libraries, and give the explicit file names of any
library built by your package. Doing so will ensure that
`maude_DEPENDENCIES' (see below) is correctly defined by default.
This suggests to me that we shouldn't use LDFLAGS at all for any -lguile
-L/usr/local/lib stuff, and I installed the following patch.
Does this work for you?
/Simon
commit 1020d967f04532f5f39f2d4906b1f1d7893c58e1
Author: Simon Josefsson <simon at josefsson.org>
Date: Fri Jun 29 16:16:24 2007 +0200
Put $(GUILE_FLAGS) in LIBADD, not LDFLAGS.
Reported by ludo at gnu.org (Ludovic Courtès).
diff --git a/guile/src/Makefile.am b/guile/src/Makefile.am
index 7db4bec..daaab28 100644
--- a/guile/src/Makefile.am
+++ b/guile/src/Makefile.am
@@ -46,18 +46,17 @@ GNULIB_CFLAGS = -I$(top_builddir)/lgl -I$(top_srcdir)/lgl
libguile_gnutls_v_0_la_SOURCES = core.c errors.c utils.c
libguile_gnutls_v_0_la_CFLAGS = \
$(AM_CFLAGS) $(GNULIB_CFLAGS) $(GUILE_CFLAGS)
-libguile_gnutls_v_0_la_LDFLAGS = $(GUILE_LDFLAGS)
-libguile_gnutls_v_0_la_LIBADD = \
- $(GNUTLS_CORE_LIBS) $(GNULIB_LIBS)
+libguile_gnutls_v_0_la_LIBADD = \
+ $(GNUTLS_CORE_LIBS) $(GNULIB_LIBS) \
+ $(GUILE_LDFLAGS)
libguile_gnutls_extra_v_0_la_SOURCES = extra.c
libguile_gnutls_extra_v_0_la_CFLAGS = \
$(AM_CFLAGS) $(GNULIB_CFLAGS) $(GUILE_CFLAGS)
-libguile_gnutls_extra_v_0_la_LDFLAGS = $(GUILE_LDFLAGS)
libguile_gnutls_extra_v_0_la_LIBADD = \
$(GNUTLS_CORE_LIBS) $(GNUTLS_EXTRA_LIBS) \
$(builddir)/libguile-gnutls-v-0.la \
- $(GNULIB_LIBS)
+ $(GNULIB_LIBS) $(GUILE_LDFLAGS)
AM_CPPFLAGS = -I$(top_builddir) -I$(builddir)
More information about the Gnutls-dev
mailing list