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 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/
Home |
Main Index |
Thread Index |
Old Index