Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-22 Thread Jirka Hladky 
On Tuesday, June 22, 2010 02:59:58 pm Jeff Squyres wrote:
> On Jun 22, 2010, at 8:48 AM, Jirka Hladky wrote:
> > So basically, until libtool patch will make through upstream into other
> > distributions it will be needed to patch configure script.
> 
> Bummer.  But at least it's a good explanation and a workaround!

I'm working with libtool developers to resolve it.  

Thanks
Jirka

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-22 Thread Jeff Squyres 
On Jun 22, 2010, at 8:48 AM, Jirka Hladky wrote:

> So basically, until libtool patch will make through upstream into other
> distributions it will be needed to patch configure script.

Bummer.  But at least it's a good explanation and a workaround!

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-22 Thread Jirka Hladky 
On Tuesday, June 22, 2010 01:26:23 am Samuel Thibault wrote:
> Hello,
> 
> Jirka Hladky, le Mon 21 Jun 2010 18:54:47 +0200, a écrit :
> > I don't have "/usr/lib64" directory listed in
> > /etc/ld.so.conf. However, "/usr/lib64" is considered to be the
> > default lib location on 64-bit system.
> 
> Ok.  And libtool doesn't seem to add it by itself.  I believe that's
> where the problem resides.
> 
> > 1) Add  /usr/lib64 into /etc/ld.so.conf. It works like a charm.
> 
> Ok.
> 
> > The problem is that I cannot use this change in the build environment
> > (on a cluster of build servers for compilation on different
> > architectures)
> 
> Sure.  On the long term I wouldn't recommend adding it anyway: it's
> already being looked for by the linker.
> 
> > Samuel, do you have "/usr/lib64" directory listed in /etc/ld.so.conf
> > listed on your 64-bit Debian?
> 
> No.  Debian does not have a /usr/lib64 directory, 64bit versions are in
> /usr/lib.  For biarch system, /usr/lib/x86_64-linux-gnu will be used.
> 
> > 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.
> 
> Well, the real fix seems to me to fix
> 
> sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
> 
> into
> 
> sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/lib64 $lt_ld_extra"
> 
> on Fedora systems.
> 
> > James, any feedback on it? I'm not sure if I should blame libtool or just
> > open BZ to add "/usr/lib64" into /etc/ld.so.conf.
> 
> I believe in the current state of Fedora it's libtool that should be
> blamed.  Or Fedora and libtool should talk to each other to determine
> how libtool is supposed to discover that /usr/lib64 is in the standard
> research path.
> 
> Samuel

Hi Samuel,

I agree with you. It's issue with Fedora. 

I got good explanation from Mamoru Tasaka  at 
Discussion of RPM packaging standards and practices for Fedora 
 mailing group:

=
Well, actually the upstream libtool (Fedora uses 2.2.6a) does not take
care of /usr/lib64 for rpath (and this seems the same for the latest 2.2.8).
What I usually say is that:
--
 - Usually the reason that unneeded rpath /usr/lib64 is added to
   the rebuilt binary is that the upstream developer uses libtool
   which does not take special care of /usr/lib64 for
   sys_lib_dlsearch_path_spec, while Fedora's libtool take care of
   this by adding a patch. See the below patch:

   http://cvs.fedoraproject.org/viewvc/rpms/libtool/devel/libtool-2.2.6a-
rpath.patch?content-type=text%2Fplain=co

   So actually for most cases, the case that rpath /usr/lib64 is added
   (only for 64 bits arch) can be avoided by

sed -i.libdir_syssearch -e \
   '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' 
\
   configure

   i.e. just add the needed paths to sys_lib_dlsearch_path_spec in
   configure (note that libtool in the build directory is generated by
   configure) before calling %configure.
   - You can alternatively do "autoreconf -fi", however calling autotools
 is not recommended unless unavoidable.
--

So it is highly possible that if the upstream does not use Fedora (i.e. does 
not
use patched libtool) rpath /usr/lib64 appears on Fedora.
And I just confirmed that this method works for this package (hwloc).

Regards,
Mamoru
==

So basically, until libtool patch will make through upstream into other 
distributions it will be needed to patch configure script.

I'm glad that we have found an explanation. Problem is definitely not on your 
side.

Thanks a lot!
Jirka

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Samuel Thibault 
Jirka Hladky, le Mon 21 Jun 2010 22:30:36 +0200, a écrit :
> I'm not sure what's wrong. It seems like libtool is not smart enough to 
> recognize /usr/lib64 as default library directory on 64-bit system

Well, on Debian it's not needed (and might even be harmful).

Samuel

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Samuel Thibault 
James Laska, le Mon 21 Jun 2010 13:15:36 -0400, a écrit :
> To note, if I understand correctly, adding '/usr/lib64'
> to /etc/ld.so.conf or /etc/ld.so.conf.d/* should not be needed.

I agree.

> Anything in the standard Fedora library locations should be recognized
> and not require an additional /etc/ld.so.conf.d/conf file.

Yes.

> However, I think if you are storing the libraries in
> "/usr/lib[64]/hwloc"

Mmm, is he?  I don't think he is.

Samuel

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Samuel Thibault 
Hello,

Jirka Hladky, le Mon 21 Jun 2010 18:54:47 +0200, a écrit :
> I don't have "/usr/lib64" directory listed in 
> /etc/ld.so.conf. However, "/usr/lib64" is considered to be the
> default lib location on 64-bit system.

Ok.  And libtool doesn't seem to add it by itself.  I believe that's
where the problem resides.

> 1) Add  /usr/lib64 into /etc/ld.so.conf. It works like a charm.

Ok.

> The problem is that I cannot use this change in the build environment
> (on a cluster of build servers for compilation on different
> architectures)

Sure.  On the long term I wouldn't recommend adding it anyway: it's
already being looked for by the linker.

> Samuel, do you have "/usr/lib64" directory listed in /etc/ld.so.conf listed 
> on 
> your 64-bit Debian?

No.  Debian does not have a /usr/lib64 directory, 64bit versions are in
/usr/lib.  For biarch system, /usr/lib/x86_64-linux-gnu will be used.

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

Well, the real fix seems to me to fix

sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"

into

sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/lib64 $lt_ld_extra"

on Fedora systems.

> James, any feedback on it? I'm not sure if I should blame libtool or just 
> open 
> BZ to add "/usr/lib64" into /etc/ld.so.conf.

I believe in the current state of Fedora it's libtool that should be
blamed.  Or Fedora and libtool should talk to each other to determine
how libtool is supposed to discover that /usr/lib64 is in the standard
research path.

Samuel

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Jirka Hladky 
On Monday, June 21, 2010 09:58:08 pm Jeff Squyres wrote:
> On Jun 21, 2010, at 3:18 PM, Jirka Hladky wrote:
> > $chrpath --list /usr/local/bin/lstopo
> > /usr/local/bin/lstopo: RPATH=/usr/local/lib
> 
> Ah, I understand now.  And I'm seeing the same behavior:
> 
> $ cd util
> $ rm lstopo
> $ make V=1
> /bin/sh ../libtool  --tag=CC   --mode=link gcc -I/usr/include/cairo
> -I/usr/include/freetype2 -I/usr/include/libpng12   -I/usr/include/libxml2 
>  -std=gnu99   -fvisibility=hidden  -I/home/jsquyres/hwloc-1.0.1/include
> -L/home/jsquyres/hwloc-1.0.1/src  -o lstopo lstopo-lstopo.o
> lstopo-lstopo-color.o lstopo-lstopo-text.o lstopo-lstopo-draw.o
> lstopo-lstopo-fig.o lstopo-lstopo-cairo.o lstopo-lstopo-xml.o  -lcairo  
> -lxml2 -lz -lm   -lm -lncursesw  -lX11
> /home/jsquyres/hwloc-1.0.1/src/libhwloc.la libtool: link: gcc
> -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12
> -I/usr/include/libxml2 -std=gnu99 -fvisibility=hidden
> -I/home/jsquyres/hwloc-1.0.1/include -o .libs/lstopo lstopo-lstopo.o
> lstopo-lstopo-color.o lstopo-lstopo-text.o lstopo-lstopo-draw.o
> lstopo-lstopo-fig.o lstopo-lstopo-cairo.o lstopo-lstopo-xml.o 
> -L/home/jsquyres/hwloc-1.0.1/src -lcairo -lncursesw -lX11
> /home/jsquyres/hwloc-1.0.1/src/.libs/libhwloc.so -lxml2 -lz -lm -Wl,-rpath
> -Wl,/tmp/bogus/lib
> 
> ...and there's the -rpath in there (my prefix was /tmp/bogus, so it's
> definitely pulling it from /home/jsquyres/hwloc-1.0.1/src/libhwloc.la).
> 
> I tried building SVN with the latest latest latest GNU tools:
> 
> AM 1.11.1
> AC 2.65
> LT 2.2.8
> M4 1.4.14
> 
> And the same thing happened.  So this is what LT wants to do.  :-\
> 
> We cannot be the only project that builds both LT libraries and then
> executables from those libraries.  What do those projects do?

Hi Jeff,

I'm not sure what's wrong. It seems like libtool is not smart enough to 
recognize /usr/lib64 as default library directory on 64-bit system I have 
asked on Fedora packaging mailing list for advice. I will keep you updated.


> 
> > Please give me a pointer to 1.0.2 version. I will give it a try, perhaps
> > it has been already fixed.
> 
> My (double) bad -- the current released version is 1.0.1.  We haven't
> changed anything other than Samuels' S/LIBS/LDADD/ stuff.
 No problem:-)

Thanks
Jirka

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Jeff Squyres 
On Jun 21, 2010, at 3:18 PM, Jirka Hladky wrote:
> $chrpath --list /usr/local/bin/lstopo
> /usr/local/bin/lstopo: RPATH=/usr/local/lib

Ah, I understand now.  And I'm seeing the same behavior:

$ cd util
$ rm lstopo
$ make V=1
/bin/sh ../libtool  --tag=CC   --mode=link gcc -I/usr/include/cairo 
-I/usr/include/freetype2 -I/usr/include/libpng12   -I/usr/include/libxml2   
-std=gnu99   -fvisibility=hidden  -I/home/jsquyres/hwloc-1.0.1/include 
-L/home/jsquyres/hwloc-1.0.1/src  -o lstopo lstopo-lstopo.o 
lstopo-lstopo-color.o lstopo-lstopo-text.o lstopo-lstopo-draw.o 
lstopo-lstopo-fig.o lstopo-lstopo-cairo.o lstopo-lstopo-xml.o  -lcairo   -lxml2 
-lz -lm   -lm -lncursesw  -lX11 /home/jsquyres/hwloc-1.0.1/src/libhwloc.la
libtool: link: gcc -I/usr/include/cairo -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/libxml2 -std=gnu99 -fvisibility=hidden 
-I/home/jsquyres/hwloc-1.0.1/include -o .libs/lstopo lstopo-lstopo.o 
lstopo-lstopo-color.o lstopo-lstopo-text.o lstopo-lstopo-draw.o 
lstopo-lstopo-fig.o lstopo-lstopo-cairo.o lstopo-lstopo-xml.o  
-L/home/jsquyres/hwloc-1.0.1/src -lcairo -lncursesw -lX11 
/home/jsquyres/hwloc-1.0.1/src/.libs/libhwloc.so -lxml2 -lz -lm -Wl,-rpath 
-Wl,/tmp/bogus/lib

...and there's the -rpath in there (my prefix was /tmp/bogus, so it's 
definitely pulling it from /home/jsquyres/hwloc-1.0.1/src/libhwloc.la).  

I tried building SVN with the latest latest latest GNU tools:

AM 1.11.1
AC 2.65
LT 2.2.8
M4 1.4.14

And the same thing happened.  So this is what LT wants to do.  :-\

We cannot be the only project that builds both LT libraries and then 
executables from those libraries.  What do those projects do?

> Please give me a pointer to 1.0.2 version. I will give it a try, perhaps it
> has been already fixed.

My (double) bad -- the current released version is 1.0.1.  We haven't changed 
anything other than Samuels' S/LIBS/LDADD/ stuff.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Jirka Hladky 
On Monday, June 21, 2010 09:07:35 pm Jeff Squyres wrote:
> 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?

Hi Jeff,

I'm using default macro 
%configure

in RPM spec file

which will set appropriate location for libraries, binaries, etc. This is the 
result:
==
+ ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu 
--target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-
prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --
datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --
libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --
mandir=/usr/share/man --infodir=/usr/share/info
==

> 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:
You need to check the binary, not library. I'm using chrpath utility. On my 
Fedora it's part of chrpath package (chrpath-0.13-6.fc12.x86_64)

$which lstopo 
/usr/local/bin/lstopo

$chrpath --list /usr/local/bin/lstopo
/usr/local/bin/lstopo: RPATH=/usr/local/lib


> 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).
I completely agree with you!

Please give me a pointer to 1.0.2 version. I will give it a try, perhaps it 
has been already fixed.

Thanks
Jirka

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Jeff Squyres 
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
de27 l F .text  019d  
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
include ld.so.conf.d/*.conf
[11:32] svbu-mpi:~/svn/ompi/ompi/mpi/c % more /etc/ld.so.conf.d/*
/usr/lib64/qt-3.3/lib
[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).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Jirka Hladky 
On Monday, June 21, 2010 04:51:09 pm Samuel Thibault wrote:
> Jeff Squyres, le Mon 21 Jun 2010 10:48:13 -0400, a écrit :
> > I still see -rpath being inserted in the final link step for libhwloc.so
> > (SVN build using AC 2.65, AM 1.11.1, LT 2.2.6b):
> > 
> > /bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99  
> > -fvisibility=hidden -I/usr/include/libxml2   -std=gnu99  
> > -fvisibility=hidden  -I/users/jsquyres/svn/hwloc/include -Wall
> > -Wunused-parameter -Wundef -Wno-long-long -Wsign-compare
> > -Wmissing-prototypes -Wstrict-prototypes -Wcomment -pedantic   
> > -no-undefined  -version-number 0:0:0 -lxml2 -lz -lm-o libhwloc.la
> > -rpath /home/jsquyres/bogus/lib topology.lo traversal.lo
> > topology-synthetic.lo bind.lo cpuset.lo misc.lo topology-xml.lo 
> > topology-linux.lo   topology-x86.lo  -libverbs
> > 
> > But unless I'm mistaken, libtool then strips 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 -libverbs-Wl,-soname -Wl,libhwloc.so.0 -o
> > .libs/libhwloc.so.0.0.0
> 
> I was also seeing that behavior with LIBS, so I don't think turning to
> LDADD fixed that part.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Hi Samuel,

thanks a lot for looking into it! I have done some research on Fedora12 and 
Fedora13, both 64-bit.

I don't have "/usr/lib64" directory listed in /etc/ld.so.conf. However,  
"/usr/lib64" is considered to be the default lib location on 64-bit system. 
ldconfig is looking into /usr/lib64 by default.

However, libtool does not look into /usr/lib64 by default. I have found 2 ways 
how to fix it:

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.

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.

James, any feedback on it? I'm not sure if I should blame libtool or just open 
BZ to add "/usr/lib64" into /etc/ld.so.conf.

Thanks
Jirka

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Samuel Thibault 
Jeff Squyres, le Mon 21 Jun 2010 10:48:13 -0400, a écrit :
> I still see -rpath being inserted in the final link step for libhwloc.so (SVN 
> build using AC 2.65, AM 1.11.1, LT 2.2.6b):
> 
> /bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99   
> -fvisibility=hidden -I/usr/include/libxml2   -std=gnu99   -fvisibility=hidden 
>  -I/users/jsquyres/svn/hwloc/include -Wall -Wunused-parameter -Wundef 
> -Wno-long-long -Wsign-compare -Wmissing-prototypes -Wstrict-prototypes 
> -Wcomment -pedantic-no-undefined  -version-number 0:0:0 -lxml2 -lz -lm
> -o libhwloc.la -rpath /home/jsquyres/bogus/lib topology.lo traversal.lo 
> topology-synthetic.lo bind.lo cpuset.lo misc.lo topology-xml.lo  
> topology-linux.lo   topology-x86.lo  -libverbs
> 
> But unless I'm mistaken, libtool then strips 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 -libverbs-Wl,-soname -Wl,libhwloc.so.0 -o .libs/libhwloc.so.0.0.0

I was also seeing that behavior with LIBS, so I don't think turning to
LDADD fixed that part.

Samuel

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-21 Thread Jeff Squyres 
Sorry; I was on a plane while most of this conversation was occurring on Friday.

I see that Samuel converted to use LDADD instead of LIBS.  Cool.  

I still see -rpath being inserted in the final link step for libhwloc.so (SVN 
build using AC 2.65, AM 1.11.1, LT 2.2.6b):

/bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99   -fvisibility=hidden 
-I/usr/include/libxml2   -std=gnu99   -fvisibility=hidden  
-I/users/jsquyres/svn/hwloc/include -Wall -Wunused-parameter -Wundef 
-Wno-long-long -Wsign-compare -Wmissing-prototypes -Wstrict-prototypes 
-Wcomment -pedantic-no-undefined  -version-number 0:0:0 -lxml2 -lz -lm
-o libhwloc.la -rpath /home/jsquyres/bogus/lib topology.lo traversal.lo 
topology-synthetic.lo bind.lo cpuset.lo misc.lo topology-xml.lo  
topology-linux.lo   topology-x86.lo  -libverbs

But unless I'm mistaken, libtool then strips 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 -libverbs-Wl,-soname -Wl,libhwloc.so.0 -o .libs/libhwloc.so.0.0.0

Does this latest change make it work acceptably for you?



On Jun 18, 2010, at 7:18 PM, Samuel Thibault wrote:

> Samuel Thibault, le Sat 19 Jun 2010 00:03:49 +0200, a écrit :
> > What is the output of gcc -print-search-dirs?
> 
> Ah, no, I misread the configure script, sys_lib_dlsearch_path_spec
> comes from ld.so.conf (that makes sense actually).  Could you post your
> /etc/ld.so.conf (and any file that it could include)?
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-18 Thread Samuel Thibault 
Samuel Thibault, le Sat 19 Jun 2010 00:03:49 +0200, a écrit :
> What is the output of gcc -print-search-dirs?

Ah, no, I misread the configure script, sys_lib_dlsearch_path_spec
comes from ld.so.conf (that makes sense actually).  Could you post your
/etc/ld.so.conf (and any file that it could include)?

Samuel

Re: [hwloc-devel] [hwloc-users] hwloc and rpath

2010-06-18 Thread Samuel Thibault 
Hello,

I agree that rpath should be avoided. However, hwloc itself doesn't add
any.

Jirka Hladky, le Fri 18 Jun 2010 22:09:56 +0200, a écrit :
> =
>  hwloc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/hwloc-distrib 
> ['/usr/lib64']

So apparently libtool somehow doesn't realizes that /usr/lib64 is in the
standard search path.  I'd tend to believe it's a bug in libtool or the
distribution which don't understand each other.  How does configure get
invoked?  What is the output of gcc -print-search-dirs?

(On debian, we use --libdir=/usr/lib/x86_64-linux-gnu and that doesn't
introduce any rpath).

Samuel