(I found problem ... noted at bottom of email.)

On Thu, 2 Mar 2006, Ralf Wildenhues wrote:

> Erm.  Please try this also: set hardcode_into_libs=yes in the libtool,
> then build.

I didn't try yet, since I was told this was already in it.

So that is part of my problem -- I am using the wrong libtool.

I started with a directory that has no libtool and no ltmain.sh. I used a 
autogen.sh that does: "autoreconf -v --install" so that runs libtoolize.
I am not sure how or where my libtool command is generated.

So starting from scratch, I did:

env ACLOCAL="aclocal -I /home/reed/xorg/share/aclocal/" autoreconf -v --install --debug

env PKG_CONFIG_PATH=/home/reed/xorg/lib/pkgconfig ./configure --prefix=/home/reed/xorg

The new ltmain.sh is identical to my 
/home/reed/pkg/share/libtool/ltmain.sh installed from the 
libtool-base-1.5.22nb2.

The libtool is different though. The diff is 365 lines long so I won't 
include it here, but here is part of the diff:

--- /home/reed/pkg/bin/libtool  2006-03-01 10:16:16.000000000 -0800
+++ libtool     2006-03-02 09:47:21.000000000 -0800
@@ -1,7 +1,7 @@
 #! /bin/sh
 
 # libtoolT - Provide generalized library-building support services.
-# Generated automatically by  (GNU libtool 1.5.22)
+# Generated automatically by  (GNU libXfontcache 1.0.1)
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 #
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001
@@ -62,12 +62,12 @@
 allow_libtool_libs_with_static_runtimes=no
 
 # Whether or not to optimize for fast installation.
-fast_install=needless
+fast_install=yes
 
 # The host system.
-host_alias=i386-pc-dragonfly
-host=i386-pc-dragonfly
-host_os=dragonfly
+host_alias=
+host=i386-unknown-dragonfly1.5.0
+host_os=dragonfly1.5.0
 
 # The build system.
 build_alias=
@@ -82,28 +82,28 @@
 AR_FLAGS="cru"
 
 # A C compiler.
-LTCC="cc"
+LTCC="gcc"
 
 # LTCC compiler flags.
-LTCFLAGS="-I/home/reed/pkg/include/ -mtune=pentiumpro -I/usr/include"
+LTCFLAGS="-g -O2"
 
 # A language-specific compiler.
-CC="cc"
+CC="gcc"
 
 # Is the compiler the GNU C compiler?
 with_gcc=yes

...

 # Library versioning type.
-version_type=linux
+version_type=freebsd-elf

...

 # Whether we should hardcode library paths into libraries.
-hardcode_into_libs=yes
+hardcode_into_libs=no


Looks like this was created using /home/reed/pkg/share/aclocal/libtool.m4.

If it is "dragonfly*" and not freebsd[[123]]*, then the version_type is 
"freebsd-elf". And then since it is not "freebsd", then it never 
specifically defines hardcode_into_libs=yes.

So I removed the generated libtool and created a symlink as a workaround 
to my libtool script (direct from latest pkgsrc package) and all was well:

# objdump -x  /home/reed/xorg/lib/libXfontcache.so.1.0.0 | grep RPATH
  RPATH       /home/reed/xorg/lib:/usr/lib/gcc34:/usr/lib


Now I see this is documented for pkgsrc in 
pkgsrc/devel/libtool/patches/manual.README (see the CVS URL I provided 
yesterday) which says that a patch is provided for the libtool.m4 file 
(which does work), but:

   These patches are not part of the automatic patches because libtool 
   also installs these .m4 files at runtime, and we want the 
   "off-the-shelf" versions of those files used instead.

Well in this case, the "off-the-shelf" version does not work on DragonFly.

Until fixes go upstream for at least DragonFly, the libtool.m4 could be 
patched and then pkgsrc's custom manual-libtool.m4 could be a diff against 
that.

 Jeremy C. Reed

 	  	 	 BSD News, BSD tutorials, BSD links
	  	 	 http://www.bsdnewsletter.com/