Bug 69801

(In reply to comment #0)
> libtool: link: gcc [...] -I/usr/local/include -o
> .libs/dbus-run-session dbus-run-session.o -Wl,-E  -L/usr/local/lib
> -L../dbus/.libs -ldbus-1 -lpthread -Wl,-rpath,/usr/local/lib

This is explicitly linking the executable against /usr/local/lib/libdbus-1.so (further up the search path than ../dbus/.libs)...

> dbus-run-session.o(.text+0x9f5): In function `main':
> : undefined reference to `dbus_setenv'

... and your installed libdbus-1.so is an older version that doesn't export dbus_setenv(), so, unsurprisingly, the link fails.

> Even GNU libtool installed, the built-in libtool used.

If "the built-in libtool" is broken, I'm not going to work around it.

In the same situation (linking within the tree), I believe GNU libtool explicitly tells the linker to link ../dbus/.libs/libdbus-1.so (by name, instead of via -L... -ldbus-1). That's the correct thing here.

I suspect that any project that builds a library and some utilities that use that library, and uses recent library API in those utilities, will suffer a similar problem with this libtool implementation. Quite a lot of projects do that.

If you run "glibtoolize" (libtoolize with GNU libtool), it might fix this. I'd accept a patch that made autogen.sh try glibtoolize before libtoolize; or one that documented that we specifically need *GNU* libtool, not some imitation.

(In reply to comment #1)
> (In reply to comment #0)
> > libtool: link: gcc [...] -I/usr/local/include -o
> > .libs/dbus-run-session dbus-run-session.o -Wl,-E  -L/usr/local/lib
> > -L../dbus/.libs -ldbus-1 -lpthread -Wl,-rpath,/usr/local/lib
> 
> This is explicitly linking the executable against
> /usr/local/lib/libdbus-1.so (further up the search path than
> ../dbus/.libs)...
> 
> > dbus-run-session.o(.text+0x9f5): In function `main':
> > : undefined reference to `dbus_setenv'
> 
> ... and your installed libdbus-1.so is an older version that doesn't export
> dbus_setenv(), so, unsurprisingly, the link fails.

That's it, however, it's an issue why libtool doesn't use the one in build tree but the installed one.

I just checked that the libtool is GNU libtool, generated from ltmain.sh which is from the GNU libtool, diff says they're identical.

> 
> > Even GNU libtool installed, the built-in libtool used.
> 
> If "the built-in libtool" is broken, I'm not going to work around it.

False issue, the GNU libtool was used but cause the above failure.

Do you have a non-empty LDFLAGS or LD_LIBRARY_PATH?

This:

> -L/usr/local/lib

is probably the root cause. How is that getting onto your compiler command line?

(In reply to comment #4)
> Do you have a non-empty LDFLAGS or LD_LIBRARY_PATH?
> 
> This:
> 
> > -L/usr/local/lib
> 
> is probably the root cause. How is that getting onto your compiler command
> line?

Yes, in *BSD favour, all of packages installed with prefix /usr/local, so I need configure CFLAGS=-I/usr/local/include and LDFLAGS=-L/usr/local/lib to make it find header/libs.

That's just the same on FreeBSD 9.1.1, so far, not checked the status on NetBSD.

Within the configure generated on OpenBSD 5.3, below lines do cause the problem

    openbsd*)
      if test -f /usr/libexec/ld.so; then
        hardcode_direct=yes
        hardcode_shlibpath_var=no
        hardcode_direct_absolute=yes

(In reply to comment #6)
> Within the configure generated on OpenBSD 5.3, below lines do cause the
> problem
> 
>     openbsd*)
>       if test -f /usr/libexec/ld.so; then
>         hardcode_direct=yes
>         hardcode_shlibpath_var=no
>         hardcode_direct_absolute=yes

Still the case at libtool master branch, I'll send an email to its community for help.

You could try changing the check for Expat to use pkg-config, something like this (untested):

PKG_CHECK_MODULES([EXPAT], [expat])

then replacing XML_CFLAGS, XML_LIBS with EXPAT_CFLAGS, EXPAT_LIBS throughout.

The .pc file is new in Expat 2.1.0, but that was released in 2012, and users of older platforms can use EXPAT_CFLAGS and EXPAT_LIBS to set the location of Expat. This would only be OK on the development branch, obviously.

(In reply to comment #8)
> PKG_CHECK_MODULES([EXPAT], [expat])
> 
> then replacing XML_CFLAGS, XML_LIBS with EXPAT_CFLAGS, EXPAT_LIBS throughout

... which would hopefully mean you didn't need to set CFLAGS or LDFLAGS (which are too broad, especially LDFLAGS).

In particular, LDFLAGS is the wrong place to put -L - you can sometimes get into precedence problems like this one.

Created attachment 130744 [details] [review]
Autotools build: Use pkg-config to find libexpat

The version of expat that added the .pc file was released in 2012.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69801
Signed-off-by: Simon McVittie <smcv@collabora.com>

---

I think this will fix the bug by making it unnecessary to use LDFLAGS=-L/usr/local/lib. It's a good change in any case.

Created attachment 130745 [details] [review]
build: Remove indirection from uses of Expat

We haven't supported XML libraries other than Expat since 2013.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69801
Signed-off-by: Simon McVittie <smcv@collabora.com>

There are a lot of compiler warnings, but with --enable-compile-warnings=yes (instead of the default error) it does seem to work.

Comment on attachment 130744 [details] [review]
Autotools build: Use pkg-config to find libexpat

Review of attachment 130744 [details] [review]:
-----------------------------------------------------------------

r+

Comment on attachment 130745 [details] [review]
build: Remove indirection from uses of Expat

Review of attachment 130745 [details] [review]:
-----------------------------------------------------------------

r+

Thanks, fixed in git for 1.11.14.