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 
to libXft.so.2.0.

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 
roughly like:

	gcc -o conftest conftest.c -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib
		-Wl,-R/usr/pkg/lib -L/usr/pkg/lib
		-lpangoxft-1.0 -lpangox-1.0 -lgobject-2.0 -lgmodule-2.0
		-lglib-2.0 -lpthread

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.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>