gnome-keyring -2.91.4 compilation problem against older installation

[Ingo Krabbe <ikrabbe ask gmail com>]

Hi,

I'm quite interested in this problem, as it popped up first, when I
tried to compile gtk+3 with plain GNU autotools.  I found out, that
there is a problem in using libtool within gtk-doc rules, as gtk-doc
generates temporary executables to scan the code.

These temporary executables have to be executed during compilation phase
within the compilation work tree, before the package has been installed.

Libtool now has some problems to sort the LD_LIBRARY_PATH for such
executions, and sometimes pushes /usr/lib64/ to the front of it, which
makes previously, possibly older versions of some bound library, to be
found before the newly compiled libraries within the work tree.

Hmm, that sounds complex: Let's see the example: 
gnome-keyring:

gtk-doc: Compiling scanner
libtool: compile:  x86_64-pc-linux-gnu-gcc -Wall -Wchar-subscripts
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wpointer-arith
-Wcast-align -Wsign-compare -march=core2 -msse4 -mcx16 -mpopcnt -msahf
-O2
-pipe -Wno-strict-aliasing -Wno-sign-compare -I../../.. -I../../..
-pthread
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Wno-error -Wall
-Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs
-Wpointer-arith -Wcast-align -Wsign-compare -march=core2 -msse4 -mcx16
-mpopcnt
-msahf -O2 -pipe -Wno-strict-aliasing -Wno-sign-compare -c gcr-scan.c
-fPIC
-DPIC -o .libs/gcr-scan.o

gtk-doc: Linking scanner
libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wchar-subscripts
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wpointer-arith
-Wcast-align -Wsign-compare -march=core2 -msse4 -mcx16 -mpopcnt -msahf
-O2
-pipe -Wno-strict-aliasing -Wno-sign-compare -Wl,-O1 .libs/gcr-scan.o
-pthread
-Wl,-O1 -o .libs/gcr-scan  /usr/lib64/libgobject-2.0.so
/usr/lib64/libgthread-2.0.so -lrt /usr/lib64/libglib-2.0.so
../../../gcr/.libs/libgcr.so ../../../gck/.libs/libgck.so
-Wl,--as-needed
-pthread

gtk-doc: Running scanner gcr-scan
/var/tmp/portage/gnome-base/gnome-keyring-2.91.4/work/gnome-keyring-2.91.4/docs/reference/gcr/.libs/gcr-scan:
symbol lookup error:
/var/tmp/portage/gnome-base/gnome-keyring-2.91.4/work/gnome-keyring-2.91.4/docs/reference/gcr/.libs/gcr-scan:
undefined symbol: gcr_pkcs11_certificate_get_type
>>>
../../gcr/.libs/libgcr.so

This is the libtool bug!

The most simple solution to this problem is to

 * temporary remove '/usr/lib64/libgcr.'*

and install the update after successfull merge.  But I don't really like
that solution.

I already proposed a patch to libtool, that makes it figure out, that
"local paths" within the worktree always come before global paths in the
LD_LIBRARY_PATH calculation.

But I need some packages that fail this way, to confirm the need and
usefullness of that patch.

Actually gtk+3 is thought to be build with jhbuild.  This bug might
occur only without jhbuild.  I don't have jhbuild setup and I don't want
YABT (yet another build tool).

Please tell me:

A) Can you confirm the error messages when updating gnome-keyring over
some old version
B) Can you confirm the solution by removing '/usr/lib'*'/libgcr.'* ?
C) Might you know about that problem and already found another patch or
solution for libtool or some other component.
D) You don't have that problem, so what libtool version you used and
which was libgcr.so from before you installed the update.

I have:

* libtool (GNU libtool) 2.4
* an old version from gnome-base/gnome-keyring-2.30.2


tia ingo

-- 
i don't do signatures