On Mon, 2 Sep 2002, Geoffrey Furnish wrote:
> Okay, I stuided this a little after getting some zzz's, and its not
> what I thought.
> I got thorugh this by setting LD_LIBRARY_PATH so that it would find
> the prefix area that I'm building against. My memory is foggy, did we
> ordinarily have to do this before? Intuitively, I would expect the
> software to build without LD_LIBRARY_PATH set, but probably not run
> without it set (for prefixen not listed in ld.so.conf). But usually I
> have my LD_L_P set to the prefix in my .cshrc, but this came up this
> time because I'm setting up a new prefix area.
I had e-mail all prepared about my independent guess that LD_LIBRARY_PATH
was the answer for non-standard itcl, itk library locations, but great
minds think alike!
Here is my mental model of what is going on. For the old style linking of
applications where every library was mentioned, the libraries were found by
the linker using the -L option. For the new hierarchical style linking, the
application simply links against libplplottcltk. But I guess the linker
really needs to know the location of every library that libplplottcltk (not
the application) is linked with. So for non-standard library locations of
libitcl, libitk, etc., you must use LD_LIBRARY_PATH just as you would when
running the application.
I am really glad that you now have dynamic drivers working under Linux.
Please take this week to throw every test you can think of at the current
system including all the dynamic loading of libraries under tclsh and wish.
If those tests work, and you and Joao are happy with the underlying linking
design *for Linux*, then I think the next step is to make non-dynamic
drivers work for shared libraries under Linux.