Julio M. Merino Vidal wrote:
> On Mon, 2005-03-28 at 17:21 -0500, Johnny Lam wrote:
> 
>>Julio M. Merino Vidal wrote:
> 
> 
>>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.
> 
> 
> Maybe this has something to do with the dependency_libs variable in the
> .la files, which is empty.  When building pango from sources (that is,
> without buildlink), the variable includes, among other things, a path
> to /usr/pkg/lib/libXft.la.

I poked into this further.  It looks like pango should be configured 
with --enable-explicit-deps or else it always strips out the 
dependency_libs line of the installed *.la files.  I have no idea why 
you'd want to "sanitize" the *.la files in this way as it explicitly 
breaks how libtool works, but that's what the pango Makefiles do.  This 
change (adding the new configure argument) should probably be done and 
the PKGREVISION of pango should be bumped.

I'm still investigating why the wrong libXft.so is being used.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>