pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: libtool without pkgsrc on DragonFly and no RPATH (fwd)

(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 I used a 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 

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

The new is identical to my 
/home/reed/pkg/share/libtool/ installed from the 

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
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001
@@ -62,12 +62,12 @@
 # Whether or not to optimize for fast installation.
 # The host system.
 # The build system.
@@ -82,28 +82,28 @@
 # A C compiler.
 # LTCC compiler flags.
-LTCFLAGS="-I/home/reed/pkg/include/ -mtune=pentiumpro -I/usr/include"
+LTCFLAGS="-g -O2"
 # A language-specific compiler.
 # Is the compiler the GNU C compiler?


 # Library versioning type.


 # Whether we should hardcode library paths into libraries.

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/ | 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 

 Jeremy C. Reed

                         BSD News, BSD tutorials, BSD links

Home | Main Index | Thread Index | Old Index