OK more information and a workaround (problem on aix, workaround on aix) for e.g. dxexec. If there is libMagick.so at or before libMagick.a during the link, the (dump-H) header will read "libMagick.so" not "libMagick.a" . libMagick.so will then be found via the path information in the executable header or via LIBPATH. LD_LIBRARY_PATH seems to be ignored by the loader. Even if they are all symlinks to the same library e.g. libMagick.so.4.0.28 the appearance of libMagick.so in the header appears to be critical, the absence of shr.o its member section may have something to do with why. Pete
Peter Daniel Kirchner wrote: > 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
