Well, thanks, but again, LD_LIBRARY_PATH isn't working for me on aix 4.3.2. When it seems to work it is only a coincidence, the load succeeds when the libMagick.so shared lib is fortuitously in one of the directories in dxexec's header. Pete
[EMAIL PROTECTED] wrote: > You need LD_LIBRARY_PATH pointing to where the shared IM is. > Also, with IM 5.1 you need to have DELEGATE_PATH pointing to where your > delegates.mgk file is located, which indicates what libraries you are > using, how various formats are handled, etc. > > As a side note, TMPDIR points to where IM makes scratch files. The default > on AIX is /tmp, /usr/tmp on Solaris, c:\temp on NT, etc... > > -------------------------- > Lloyd A. Treinish > Visual Analysis > IBM Thomas J. Watson Research Center > P. O. Box 704 > Yorktown Heights, NY 10598 > 914-784-5038 (voice) > 914-784-7667 (facsimile) > [EMAIL PROTECTED] > http://www.research.ibm.com/people/l/lloydt/ > > Peter Daniel Kirchner <[EMAIL PROTECTED]>@opendx.watson.ibm.com on > 01/13/2000 11:17:59 AM > > Please respond to opendx2-dev@lists.berlios.de > > Sent by: [EMAIL PROTECTED] > > To: opendx2-dev@lists.berlios.de > cc: > Subject: Re: [opendx-dev] javadx shareable libraries > > I've found that on AIX 4.3.2 at least, for libMagick at least that I've got > to have > the shared lib in one of the directories defined at *link time*. These > dirs can be > found in the dxexec header ( view on aix with dump -H) which includes > defaults as > well as directories specified by -L during the link. If the lib is > elsewhere, dx > won't run and the error is "could not load library libMagick.a ". Before > you leap > on the obvious: LIBPATH and LD_LIBRARY_PATH seem to have no beneficial > effect. > Anyone know what is going on here? > > Rick Scott wrote: > > > I vote with trying to go with libtool. Of course that is assuming that I > have a > > vote :) I realize that getting things to work "the libtool way" may not > be easy > > at first, but once you get it going, the routine maintainance on various > > platforms is reduced. I started off trying to tweak Makefiles by hand for > > various platforms, moved on to Imake, which was never really sucessfull > since > > most installations never had working Imake installations. From there I > moved > > into autoconf/automake, which was great for making programs, but when it > came > > to shared libraries was still a nightmare. If you can live with libtools > rules, > > you open up a whole slew of platforms that you could never test for > yourself. > > If the libtool folks know anything, they know how to make a library on > more > > platforms than the average person........ > > > > Anyway, enough of this, I have a tarball to roll, and I still may have to > > justify why I broke a code freeze to get David's "conveince" translations > > working..... So much to do, so little time........ > > > > On 12-Jan-00 at 21:11, David Thompson ([EMAIL PROTECTED]) wrote: > > > I just wanted to give everyone a heads up if they plan on dealing with > > > JavaDX. Since JavaDX must link against shared libraries at runtime, if > > > you have format such as netcdf compiling in -- that are not made as > > > shareable libraries, javadx is going to have problems. > > > > > > The solution? Not quite sure yet. I'm not positive if all of the format > > > libraries can be built as shareable or not. I've been messing around > > > with libtool, but there are some problems dealing with it as well. It > > > may be time to do a brainstorming session of how to reorganize the > > > libraries. Creating shared and static versions of each. Libtool does > > > have some excellent features but they assume that you have your project > > > set up a specific way. > > > > > > Suhaib, since I haven't compiled stuff for Windows, what is your take > on > > > using libtool? Does it solve or create problems? > > > > > > I also have some questions that I've fired off to the libtool group in > > > terms of our loadable modules. That is where I'm really stuck right > now, > > > and we'll see if libtool can accomodate for them. > > > > > > David
