Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Stefano Lattarini
On 02/26/2012 03:47 PM, Miles Bader wrote:
 I thought that as long as one used .la libraries, automake+libtool
 was supposed to handle all the grotty stuff like rpath automatically,
 adding -rpath $(libdir) if you depend on libraries installed to libdir
 and libdir isn't on the system library search path.  [Yeah, I also
 know some people hate rpath, but ...]
 
 But ... it doesn't seem to.  Is something broken, is there an option I
 should set... or?
 
 [I guess I can add -rpath blahblaha somewhere in Makefile.am, but
 I don't really want to add system-dependent stuff that libtool's
 supposed to be handling; isn't that why libtool exists in the first
 place?]
 
 automake version 1.11.3, libtool version 2.4.2
 
 Thanks,
 
 -Miles
 
 
 Example:
 
 configure.ac:
 AC_INIT([blah], [0.1], [bob])
 AM_INIT_AUTOMAKE([foreign])
 LT_INIT
 AC_PROG_CC
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 Makefile.am:
 bin_PROGRAMS = blah
 lib_LTLIBRARIES = liboink.la
 blah_SOURCES = blah.c
 blah_LDADD = liboink.la
 liboink_la_SOURCES = oink.c
 blah.c:
 extern void oink ();
 int main () { oink (); }
 oink.c:
 void oink () { }
 
 Commands:
 $ autoreconf --install
 ...
 $ ./configure
 ...
 $ make
 ...
 $ sudo make install
 ...
 $ /usr/local/bin/blah
 /usr/local/bin/blah: error while loading shared libraries: 
 liboink.so.0: cannot open shared object file: No such file or directory
 $ LD_LIBRARY_PATH=/usr/local/lib /usr/local/lib/blah
 $ ldd /usr/local/bin/blah
 linux-vdso.so.1 =  (0x7fff247c5000)
 liboink.so.0 = not found
 libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 
 (0x7f5ceeb26000)
 /lib64/ld-linux-x86-64.so.2 (0x7f5ceeed1000)
 $ readelf -d /usr/local/bin/blah | grep RPATH
 $ 
 
I must admit I know very little of the Automake's libtool support, so I'm
not sure whether this is a bug or not; still, the automake documentation
reads somewhere:

  For libraries whose destination directory is known when Automake runs,
  Automake will automatically supply the appropriate -rpath option to
  libtool. This is the case for libraries listed explicitly in some
  installable _LTLIBRARIES variables such as lib_LTLIBRARIES.

so we have *at least* a documentation issue.  I should look at this more
carefully (probably after the 1.12 release); for now, I'm opening a report
in the bug tracker so that we won't forget about the issue.

Thanks,
  Stefano






Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Miles Bader
2012年2月27日0:58 Peter Johansson troj...@gmail.com:
 On which system do you experience this? I've seen this problem on
 Fedora and the problem was that the linker search path and the dynamic
 loader search path were different. IIUC libtool sets -rpath if a used library
 is outside linker path.

Debian sid

I'm not sure how libtool determines whether or not the libdir is
outside the linker path (as it obviously is, since execution
fails... :).  If it searches /etc/ld.conf, it might get confused
because here it just says include /etc/ld.conf.d/*.conf -- but if it
gets confused, I'd think it would default to assuming it was outside
the search path, not to assuming it was in the search path.

Of course it could be some debian patch that is causing the problem,
but it sounds like not.

[I've tried a little to examine libtool to see what it's doing, but
it's ... very ... hard to read.]

 The solution for me was to include '/usr/local/lib' in '/etc/ld.so.conf' as
 suggested here
 http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html.

That's not generally a solution though, because it requires modifying /etc.

I think it's desirable that it just work wherever it gets installed,
and no matter who installs it (e.g. prefix=$HOME should work, and
shouldn't require setting LD_LIBRARY_PATH).

-miles

-- 
Cat is power.  Cat is peace.



Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Peter Johansson

On 2/26/12 11:31 PM, Miles Bader wrote:

I think it's desirable that it just work wherever it gets installed,
and no matter who installs it (e.g. prefix=$HOME should work, and
shouldn't require setting LD_LIBRARY_PATH).

In my case it did work with prefix=$HOME because in that case -rpath was 
set. Have you tried with ./configure --prefix=$HOME?


Cheers,
Peter



Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Miles Bader
2012年2月27日1:46 Peter Johansson troj...@gmail.com:
 I think it's desirable that it just work wherever it gets installed,
 and no matter who installs it (e.g. prefix=$HOME should work, and
 shouldn't require setting LD_LIBRARY_PATH).

 In my case it did work with prefix=$HOME because in that case -rpath was
 set. Have you tried with ./configure --prefix=$HOME?

Hmm, I tried:  configure --prefix=/tmp/oinker

... and it worked then!

So why is /usr/local different?

Hmm

How odd:

   $ cat /etc/ld.so.conf
   include /etc/ld.so.conf.d/*.conf

   $ cat /etc/ld.so.conf.d/*.conf
   /usr/lib/atlas
   # libc default configuration
   /usr/local/lib
   ...

So it looks like /usr/local/lib is _supposed_ to be searched.

But 
hmm
grovel, grovel

Ok, the real problem seems to be that the system maintains a static
cache of _library files_ (not directories) for ld.so to use, and
simply adding a library doesn't update this cache.

Just using the command:  sudo ldconfig
after installing my package makes everything work!

ARg

I'll refrain from commenting on the people who designed this, but
maybe a note in the automake manual saying on linux systems, you may
have to run the ldconfig program to make the system aware of newly
installed dynamic libraries in system directories. would be a good
thing...

Thanks, and sorry for the noise!

-miles

-- 
Cat is power.  Cat is peace.



Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Miles Bader
2012年2月27日9:41 Bob Friesenhahn bfrie...@simple.dallas.tx.us:
 Just using the command:  sudo ldconfig
 after installing my package makes everything work!

 This is a function that libtool normally performs if it is used properly.

I did:  sudo make install

Is that not using it properly?

-miles

-- 
Cat is power.  Cat is peace.



Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Russ Allbery
Miles Bader mi...@gnu.org writes:
 2012年2月27日9:41 Bob Friesenhahn bfrie...@simple.dallas.tx.us:

 This is a function that libtool normally performs if it is used properly.

 I did:  sudo make install

 Is that not using it properly?

Something needs to run libtool --mode=finish.  I thought Automake normally
arranged to run that at the end of make install.  Is that not happening
for some reason?

libtool --mode=finish will run ldconfig.  It's much of the point of having
a separate finish mode.

-- 
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/



Re: Wait, isn't rpath supposed to be set automagically?

2012-02-26 Thread Miles Bader
2012年2月27日16:21 Russ Allbery r...@stanford.edu:
 This is a function that libtool normally performs if it is used properly.

 I did:  sudo make install

 Something needs to run libtool --mode=finish.  I thought Automake normally
 arranged to run that at the end of make install.  Is that not happening
 for some reason?

I don't see anything like that in the Makefile.in generated by
automake (using the example project from my initial message in this
thread)...

$ grep finish Makefile.in
$

hmm

-miles

-- 
Cat is power.  Cat is peace.