From: Alan W. I. <ir...@be...> - 2002-09-02 17:50:14
|
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. Alan |