LD_LIBRARY_PATH problems

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

LD_LIBRARY_PATH problems

Paul Kienzle-2
Hi,

I've been trying to track down a problem in input.cc which comes about when I
have a really long input line:

        input.cc:307: int octave_read (char *, unsigned int): Assertion `len > 0' failed.
        panic: Aborted -- stopping myself...

In the process of fixing it, I needed to override liboctinterp.so, so taking
some lines from test/Makefile I did the following:

        #! /bin/sh

        BASE=/home/pkienzle/cvs/octave
        OCTAVE=$BASE/src/octave
        ARGS="--norc --path .:$BASE/scripts//:$BASE/src"
        LIBPATH=$BASE/libcruft:$BASE/liboctave:$BASE/src
        LD_LIBRARY_PATH=$LIBPATH ldd $OCTAVE
        LD_LIBRARY_PATH=$LIBPATH $OCTAVE $ARGS

This didn't work.  The "ldd" command shows that it is still picking up
files from /usr/local/lib.  

A warning to other maintainers: before running make check, you should
first run the above script and check that you are picking up the correct
libraries.

Looking at the ld.so man page, it seems to check for libraries in the
following order

        RPATH section of object
        LD_LIBRARY_PATH environment variable
        RUNPATH section of object
        /etc/ld.so.cache

Looking at my Makeconf, I see that RLD_FLAG contains -Xlinker -rpath, so ld
is doing what it claims.  Presumably the --disable-rpath option on ./configure
will make things work right, but I haven't checked (it takes a looong time to
compile on this box).

So my question is, is there any way to override the builtin rpath?

Using LD_PRELOAD I can explicitly load the libraries but this runs into another
problem: liboct-pathsearch depends on symbols from libkpathsea.a which for
some reason is linked into src/octave directly.  I haven't tried linking it
into liboct-pathsearch (again, it takes a long time to compile), but that might
fix it.

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

LD_LIBRARY_PATH problems

John W. Eaton-6
On 14-Aug-2002, Paul Kienzle <[hidden email]> wrote:

| Looking at my Makeconf, I see that RLD_FLAG contains -Xlinker
| -rpath, so ld is doing what it claims.  Presumably the
| --disable-rpath option on ./configure will make things work right,
| but I haven't checked (it takes a looong time to compile on this box).

But you already have it built, right?  The -rpath option is only used
at link time, so it should be relatively fast to relink without that
option.  Even if you run configure again with --disable-rpath, you
should only have to recompile src/toplev.o and then relink.

| libkpathsea.a which for
| some reason is linked into src/octave directly.  I haven't tried linking it
| into liboct-pathsearch

Oh, OK.  I'll try that since that would seem to be the logical place
for it.

BTW, the reason we still have to have our own libkpathsearch instead
of depending on some external package is that there are two
modifications necessary for running Octave with kpathsearch.  One
avoids a memory leak and the other allows us to reset the search path
at any time.  I've sent a report and patches to the tex-k mailing list
but have never received any reply.  If someone would like to pursue
this (i.e., hound them unmercifully until they agree to include the
patch) then I can send you my copy of my message with the patches.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: LD_LIBRARY_PATH problems

Paul Kienzle-2
On Wed, Aug 14, 2002 at 01:17:48PM -0500, John W. Eaton wrote:

> On 14-Aug-2002, Paul Kienzle <[hidden email]> wrote:
>
> | Looking at my Makeconf, I see that RLD_FLAG contains -Xlinker
> | -rpath, so ld is doing what it claims.  Presumably the
> | --disable-rpath option on ./configure will make things work right,
> | but I haven't checked (it takes a looong time to compile on this box).
>
> But you already have it built, right?  The -rpath option is only used
> at link time, so it should be relatively fast to relink without that
> option.  Even if you run configure again with --disable-rpath, you
> should only have to recompile src/toplev.o and then relink.

It seemed to be rebuilding everything in src.  It's too late to check
now since I restarted from scratch.

BTW, while rebuilding I encountered the following:

        odepack/pic/xerrwv.o: In function `xerrwv_':
        odepack/pic/xerrwv.o(.text+0x0): multiple definition of `xerrwv_'
        dasrt/pic/xerrwv.o(.text+0x0): first defined here

I removed dasrt/xerrwv.f

Paul Kienzle


Reply | Threaded
Open this post in threaded view
|

Re: LD_LIBRARY_PATH problems

Paul Kienzle-2
In reply to this post by Paul Kienzle-2
--disable-rpath doesn't work when you install octave since octave libs aren't
in the standard place.  

Here's the script I use for running a test version of an already installed
version of octave compiled with --rpath:

#! /bin/sh

BASE=/home/pkienzle/cvs/octave
OCTAVE=$BASE/src/octave
ARGS="--norc --path .:$BASE/scripts//:$BASE/src"
LIBPATH=$BASE/libcruft:$BASE/liboctave:$BASE/src

# LD_LIBRARY_PATH works fine in the installed version is different from
# the test version.  If it is the same, the --rpath will pick up the
# installed libraries without even checking the LD_LIBRARY_PATH.

#LD_LIBRARY_PATH=$LIBPATH ldd $OCTAVE
#LD_LIBRARY_PATH=$LIBPATH $OCTAVE $ARGS
#exit

# Since LD_LIBRARY_PATH doesn't work we will preload explicitly named libraries
CRUFT=$BASE/libcruft/libcruft.so
LIBOCTAVE=$BASE/liboctave/liboctave.so
PATHSEARCH=$BASE/liboctave/liboct-pathsearch.so
READLINE=$BASE/liboctave/liboct-readline.so
INTERP=$BASE/src/liboctinterp.so

# Can't preload $PATHSEARCH because it requires symbols from src/octave
# Instead set LD_LIBRARY_PATH so we can pick it up from testoct.  
# The LD_LIBRARY_PATH is ignored for cvs.
PRELOAD=$CRUFT:$LIBOCTAVE:$INTERP:$READLINE
export LD_LIBRARY_PATH=$BASE/liboctave

LD_PRELOAD=$PRELOAD ldd $OCTAVE
LD_PRELOAD=$PRELOAD $OCTAVE $ARGS

Paul Kienzle
[hidden email]

On Wed, Aug 14, 2002 at 01:34:44PM -0400, Paul Kienzle wrote:

> Hi,
>
> I've been trying to track down a problem in input.cc which comes about when I
> have a really long input line:
>
> input.cc:307: int octave_read (char *, unsigned int): Assertion `len > 0' failed.
> panic: Aborted -- stopping myself...
>
> In the process of fixing it, I needed to override liboctinterp.so, so taking
> some lines from test/Makefile I did the following:
>
> #! /bin/sh
>
> BASE=/home/pkienzle/cvs/octave
> OCTAVE=$BASE/src/octave
> ARGS="--norc --path .:$BASE/scripts//:$BASE/src"
> LIBPATH=$BASE/libcruft:$BASE/liboctave:$BASE/src
> LD_LIBRARY_PATH=$LIBPATH ldd $OCTAVE
> LD_LIBRARY_PATH=$LIBPATH $OCTAVE $ARGS
>
> This didn't work.  The "ldd" command shows that it is still picking up
> files from /usr/local/lib.  
>
> A warning to other maintainers: before running make check, you should
> first run the above script and check that you are picking up the correct
> libraries.
>
> Looking at the ld.so man page, it seems to check for libraries in the
> following order
>
> RPATH section of object
> LD_LIBRARY_PATH environment variable
> RUNPATH section of object
> /etc/ld.so.cache
>
> Looking at my Makeconf, I see that RLD_FLAG contains -Xlinker -rpath, so ld
> is doing what it claims.  Presumably the --disable-rpath option on ./configure
> will make things work right, but I haven't checked (it takes a looong time to
> compile on this box).
>
> So my question is, is there any way to override the builtin rpath?
>
> Using LD_PRELOAD I can explicitly load the libraries but this runs into another
> problem: liboct-pathsearch depends on symbols from libkpathsea.a which for
> some reason is linked into src/octave directly.  I haven't tried linking it
> into liboct-pathsearch (again, it takes a long time to compile), but that might
> fix it.
>
> Paul Kienzle
> [hidden email]
>


Reply | Threaded
Open this post in threaded view
|

Re: LD_LIBRARY_PATH problems

Mumit Khan-4
In reply to this post by Paul Kienzle-2
On Wed, 14 Aug 2002, Paul Kienzle wrote:

> BTW, while rebuilding I encountered the following:
>
> odepack/pic/xerrwv.o: In function `xerrwv_':
> odepack/pic/xerrwv.o(.text+0x0): multiple definition of `xerrwv_'
> dasrt/pic/xerrwv.o(.text+0x0): first defined here
>
> I removed dasrt/xerrwv.f

Same here. The object files differ in size as the sources are slightly
different, hence the problem when building shared library.

Mumit



Reply | Threaded
Open this post in threaded view
|

Re: LD_LIBRARY_PATH problems

John W. Eaton-6
On 18-Aug-2002, Mumit Khan <[hidden email]> wrote:

| On Wed, 14 Aug 2002, Paul Kienzle wrote:
|
| > BTW, while rebuilding I encountered the following:
| >
| > odepack/pic/xerrwv.o: In function `xerrwv_':
| > odepack/pic/xerrwv.o(.text+0x0): multiple definition of `xerrwv_'
| > dasrt/pic/xerrwv.o(.text+0x0): first defined here
| >
| > I removed dasrt/xerrwv.f
|
| Same here. The object files differ in size as the sources are slightly
| different, hence the problem when building shared library.

The CVS sources should have only one version of xerrwv now.

jwe