Hello Kyle,
* Kyle Wheeler wrote on Mon, Sep 18, 2006 at 07:37:40PM CEST:
>
> I have a bit of a weird setup which I’m sure is to blame for my
> problems, but I don’t know where to start digging to find the problem.
I have no idea what the underlying problem may be, so here's merely a
bunch of hints to try out and dig further.
> I have lam installed in my home directory, because it’s more recent
> (and better) than the one that’s installed system-wide. More
> specifically, they are incompatable (one uses the PGI compilers, one
> uses GCC).
If you fear that you may be using incompatible libraries at runtime, do
a
LD_DEBUG=libs $your_binary
and look for suspicious libraries in the output.
> ldd on my binary says:
>
> libaio.so.1 => /usr/lib/libaio.so.1 (0x008ee000)
> libutil.so.1 => /lib/libutil.so.1 (0x0074a000)
> libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00bfe000)
> libdl.so.2 => /lib/libdl.so.2 (0x0085f000)
> libc.so.6 => /lib/tls/libc.so.6 (0x009f2000)
> libpgc.so => /usr/pgi/linux86/6.1/lib/libpgc.so (0x0019d000)
> libm.so.6 => /lib/tls/libm.so.6 (0x006fc000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0076f000)
That doesn't contain any LAM libraries. Did you compile that
--disable-shared, or why else could that be? You may want to take a
look at "objdump -p $your_binary" to find out only direct library
dependencies.
If your binary would not find LAM libraries by default, setting
LD_LIBRARY_PATH were one way to overcome that (but above ldd output
doesn't look like it).
Otherwise, to find out exactly when the setup fails, strace and a
debugger are probably good friends. ;-)
Hope that helps a bit.
Cheers,
Ralf
|
