Subject: Re: x11/gtk2 doesn't build on Linux (SuSE 8.1)
To: Julio M. Merino Vidal <email@example.com>
From: Johnny Lam <jlam@NetBSD.org>
Date: 03/28/2005 17:21:29
Julio M. Merino Vidal wrote:
> On Mon, 2005-03-28 at 14:14 -0500, Johnny C. Lam wrote:
>>This is a problem where the pkgsrc libXft and the X11R6 libXft probably
>>have the same major number. Buildlink will force the correctly
>>libraries to be used during linking, but at run-time, the shared
>>libraries are found by searching the run-time library search path in
>>order. In this case, since /usr/X11R6/lib appears before /usr/pkg/lib
>>in the rpath, it will be searched first.
>>I believe that there is very little that we can do here to fix this
>>problem without requiring differing major numbers for the shared
>>libraries between X11R6 and pkgsrc. The search path cannot be
>>guaranteed to be correct and can actually never be correct if the user
>>chooses to use the builtin versions of some libraries while using pkgsrc
>>versions of others. While buildlink could reorder the -Wl,-R flags,
>>it's not clear how to determine what the correct order should be.
> Aha. Thanks for the explanation. Looks like we won't be able to fix
> the problem :-/
> But I still can't see why does the run path affect the build...
> shouldn't it be using the -L flags?
Actually, the problem shouldn't be cropping up here as libXft.so does
seem to have different major numbers on the shared library between the
X11R6 and pkgsrc versions on Torsten's system. As such, the run-time
linker should be able to locate libXft.so.2 in /usr/pkg/lib and not pick
up libXft.so.1 from /usr/X11R6/lib.
The information that I'd like to see are the results of:
(1) ls -l /usr/pkgsrc/x11/gtk2/work/.buildlink/lib/libXft.*
(2) objdump -p -j .dynamic /usr/X11R6/lib/libXft.so
(3) objdump -p -j .dynamic /usr/pkg/lib/libXft.so
AFAIK, when the linker sees "-lXft" on the command line, it looks for
libXft.so in the library search path (-Ldir1 -Ldir2 etc.) and extracts
the SONAME from that file to embed into the library as a shlib
dependency. I think libXft.so in the buildlink directory is pointing to
the wrong file in this case. Since we want to link against the pkgsrc
libXft.so, the libXft.so in the buildlink directory should be pointing
However, this still doesn't really explain what's going on. It appears
that the gtk2 configure script is dying when linking a line that looks
gcc -o conftest conftest.c -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib
-lpangoxft-1.0 -lpangox-1.0 -lgobject-2.0 -lgmodule-2.0
There is no "-lXft" in that link line, so it's now a question of how the
linker behaves when it needs to track down shlib dependencies. It's
possible that /usr/X11R6/lib/libXft.so doesn't have a correct SONAME
(maybe it points to itself), but barring that, it makes me wonder if
there is something different between how the linker deals with shlib
dependencies on Linux versus NetBSD. This problem needs more investigation.
-- Johnny Lam <jlam@NetBSD.org>