This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Jun 21, 2010, at 12:54 PM, Jirka Hladky wrote:
> However, libtool does not look into /usr/lib64 by default. I have found 2 ways
> how to fix it:
Are we installing to /usr/lib64 by default? Or do you have something in your specfile or your system's default that is resetting libdir to /usr/lib64?
FWIW, in the 1.0.2 distribution tarball, I'm not seeing the -rpath argument in the final libtool link. I see it in the almost-final link:
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -fvisibility=hidden -I/usr/include/libxml2 -std=gnu99 -fvisibility=hidden -I/home/jsquyres/hwloc-1.0.1/include -no-undefined -version-number 0:1:0 -lxml2 -lz -lm -o libhwloc.la -rpath /usr/local/lib topology.lo traversal.lo topology-synthetic.lo bind.lo cpuset.lo misc.lo topology-xml.lo topology-linux.lo topology-x86.lo
But then libtool seems to strip it out:
libtool: link: gcc -shared .libs/topology.o .libs/traversal.o .libs/topology-synthetic.o .libs/bind.o .libs/cpuset.o .libs/misc.o .libs/topology-xml.o .libs/topology-linux.o .libs/topology-x86.o -lxml2 -lz -lm -Wl,-soname -Wl,libhwloc.so.0 -o .libs/libhwloc.so.0.1.0
Are you seeing something different?
How does one check to see if rpath was applied to the final .libs/libhwloc.so.0.1.0? I tried objdump and didn't see anything, but I might be looking in the wrong place:
$ objdump .libs/libhwloc.so.0.1.0 -x | grep -i path
000000000000de27 l F .text 000000000000019d hwloc_strdup_mntpath
> 1) Add /usr/lib64 into /etc/ld.so.conf. It works like a charm. The problem is
> that I cannot use this change in the build environment (on a cluster of build
> servers for compilation on different architectures)
> Samuel, do you have "/usr/lib64" directory listed in /etc/ld.so.conf listed on
> your 64-bit Debian? If so, I will consider to open Bugzilla to add
> "/usr/lib64" directory into /etc/ld.so.conf on Fedora as well.
FWIW, it's not in my RHEL 5.4:
[11:32] svbu-mpi:~/svn/ompi/ompi/mpi/c % more /etc/ld.so.conf
[11:32] svbu-mpi:~/svn/ompi/ompi/mpi/c % more /etc/ld.so.conf.d/*
[11:32] svbu-mpi:~/svn/ompi/ompi/mpi/c %
> 2) Second approach is to add
> sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
> sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
> into the %configure stage in rpm specs.
> I don't like this approach but it seems to be the only way how to get rid of
> rpath on an automatic build system.
This is definitely not a preferred solution; I don't want to get in the business of frobbing a generated libtool script (we do it in Open MPI to work around esoteric bugs and it's awful awful awful).
For corporate legal information go to: