On 11/2/05, David Lyne <[EMAIL PROTECTED]> 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 typing ./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. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
