Problem with dynamic linking

Dan Nicholson dbn.lists at
Wed Nov 2 12:39:54 PST 2005

On 11/2/05, David Lyne <davelargeuk2 at> wrote:
> Sorry. I have a habit of forgetting to attach attachments 8o).

That's understandable.  It might not be appropriate to attach that to
a public mailing list, and it's huge anyway.  Anyway, I found it, so
now I'm slogging through the scripts.

> The first install script won't help anyway because I know that it
> executes without error and I'm pretty sure (by looking at it) that it
> doesn't set anything in the environment anyway.

Looks that way.  Mine might be packaged slightly differently, but I've
got a top-level shell script called installMaple, and then a file
Disk1/InstData/Linux/VM/UnixInstaller.bin.  Is LinuxInstaller.bin
actually a binary?  For me, UnixInstaller.bin is a series of shell
scripts.  If that's the case, try adding set -x below each of the
#!/bin/sh lines.  Since sh is bash on your system (probably), this
will turn on the debugging output.  Then you can see the variables as
they're set.  There's probably a slicker way to pass this in, but I
don't know.

Another thing.  For me, the top-level script only picks the Linux
directory from uname and passes parameters to the script.  So, you
could probably run UnixInstaller.bin directly.  Something I noticed in
the top-level.  You can make the installer run from the console rather
than setting up the gui by not having DISPLAY set, or by passing -i
console.  This might help.  If you run UnixInstaller.bin directly, you
can log the output to a file, too.  Try going to the directory and
./LinuxInstaller.bin -i console 2>&1 | tee /some/path/to/log

> I've been staring at the main script on and off (I have to get some work
> done today as well 8o( ) but I'm a bit of a novice so I may have to
> resort to the Bash guide first...

It's a monster, and jumps off into java which I don't understand.  It
looks like if you set LAX_DEBUG=1, you'll get some extra information
out of it.

> I've searched LinuxInstaller.bin for LD_LIBRARY_PATH (I had that idea
> too!) but there was no mention. Cheers for the hint about RPATH - I'll
> have to find out what that is.

I don't see this either, and thinking more, I don't think
LD_LIBRARY_PATH would do it.  FYI, you can find if an ELF binary has a
hardcoded run-path using objdump (from binutils).  Try objdump -p
/bin/bash.  Under the part called Dynamic Section, you'll see NEEDED
which shows the library dependecies.  Below that, if it was used, you
would see RPATH /some/path/lib.  I don't think this has anything to do
with your problems, though.

For now, could you try running the above commands (setting LAX_DEBUG,
using -i console, and logging output with tee, adding set -x to the
scripts)?  See if anything strange pops out of there.

> > You could also write to Maplesoft support and ask them what's up with
> > the installer.
> I've tried that. You can guess the answer: "LFS is not a supported
> distribution..."

What a shocker there.  Hopefully you don't get bitten by having
bleeding-edge libraries.  (We often run into this at work when
proprietary design software requires ancient libraries.  Recently, we
tried to install some software on Redhat EL3, and it used the
libstdc++ from gcc-2.95.  Ouch.)

Good luck.


More information about the lfs-support mailing list