Re: [opendx-dev] javadx shareable libraries
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
RE: [opendx-dev] javadx shareable libraries
Yes, I think so because I was using libtools snapshots (not the older released version) for what I described. Suhaib > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf > Of David L. > Thompson > Sent: Friday, January 14, 2000 12:38 AM > To: opendx2-dev@lists.berlios.de > Subject: RE: [opendx-dev] javadx shareable libraries > > > Does this include libtools 1.3.4 that was just released > about 4 weeks > ago? From what I've read, this has been greatly improved in the > latest version. > > David > > >David, > >If you allow me a 3 weeks time I would put libtools scripts > >which would work on Unices and Windows both. The main problem > >I notice with libtools, the way it is implimented in > LessTif, NetCDF, > >and ImgeMagic, is that libtools tries to create *.so files > >also on Windows. On Windows a DLL is always an executable > >and can never have an internally defined symbols. All > symbols must be > >exported from DLL. The *.lib or *.a works only as a > place holder. > > > >If you try to build NetCDF or Lesstif on Windows using > --enable-shared=yes, > >libtools will barf at you, "undefined symbols are not > supported at the > >plateform > >i686-cygwin32" and will create rubish libxxx.a and libxxx.la. > >A while ago I rewrote the configure scripts for LessTif > for Cygwin so > >creates > >DLLs on Windows and *.so on Linux. I never got a chance > to send them to > >Rick, then in a disk crash I lost the copy. > > > >The point is if you simply adopted libtools using > conventional Unices > >styles, you would > >break the libraries for Windows. > > > >Suhaib > > .. > ... > David L. Thompson The University > of Montana > mailto:[EMAIL PROTECTED] Computer > Science Department > http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 > Work Phone : > (406)257-8530 >
RE: [opendx-dev] javadx shareable libraries
Does this include libtools 1.3.4 that was just released about 4 weeks ago? From what I've read, this has been greatly improved in the latest version. David David, If you allow me a 3 weeks time I would put libtools scripts which would work on Unices and Windows both. The main problem I notice with libtools, the way it is implimented in LessTif, NetCDF, and ImgeMagic, is that libtools tries to create *.so files also on Windows. On Windows a DLL is always an executable and can never have an internally defined symbols. All symbols must be exported from DLL. The *.lib or *.a works only as a place holder. If you try to build NetCDF or Lesstif on Windows using --enable-shared=yes, libtools will barf at you, "undefined symbols are not supported at the plateform i686-cygwin32" and will create rubish libxxx.a and libxxx.la. A while ago I rewrote the configure scripts for LessTif for Cygwin so creates DLLs on Windows and *.so on Linux. I never got a chance to send them to Rick, then in a disk crash I lost the copy. The point is if you simply adopted libtools using conventional Unices styles, you would break the libraries for Windows. Suhaib . David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
RE: [opendx-dev] javadx shareable libraries
David, If you allow me a 3 weeks time I would put libtools scripts which would work on Unices and Windows both. The main problem I notice with libtools, the way it is implimented in LessTif, NetCDF, and ImgeMagic, is that libtools tries to create *.so files also on Windows. On Windows a DLL is always an executable and can never have an internally defined symbols. All symbols must be exported from DLL. The *.lib or *.a works only as a place holder. If you try to build NetCDF or Lesstif on Windows using --enable-shared=yes, libtools will barf at you, "undefined symbols are not supported at the plateform i686-cygwin32" and will create rubish libxxx.a and libxxx.la. A while ago I rewrote the configure scripts for LessTif for Cygwin so creates DLLs on Windows and *.so on Linux. I never got a chance to send them to Rick, then in a disk crash I lost the copy. The point is if you simply adopted libtools using conventional Unices styles, you would break the libraries for Windows. Suhaib > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David L. > Thompson > Sent: Thursday, January 13, 2000 6:22 PM > To: opendx2-dev@lists.berlios.de > Subject: Re: [opendx-dev] javadx shareable libraries > > > This is some of the stuff that libtool takes care of. It can take and > put the appropriate information into the header of the library and > binaries for linkages. In fact, this is how I noticed that the netcdf > and other libraries need to have shareable versions installed when > using javadx (libtool told me so.). If nothing else, I may add the > libtool functionality just for the javadx branch of the tree. But I'd > rather add full functionality right off the bat. > > One of the things that I'd like to have available while adding this > functionality is a test set that I could build for checking validity > of libs and executables. Do we have a module that would test a fair > amount of the dxlibs when linked in as an inboard, outboard, and > loadable and executed from a script? I already have the autoconf > stuff set up for most platforms for a loadable and to add the > functionality for outboard and inboard shouldn't take too much. > Something that would require DXlite and libDX might be good. (On that > thread, is there a chance that libDX could be broken into two > libraries? DXlite and OtherDX? If they were shareable, then libDX > wouldn't have to be so big.) > > Can someone send me a good dx-link program that could test the DXL > library? (Why does the shareable code with javadx only link to a > subset of DXL?) > > Opinions, suggestions? > > David > > >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 > > .. > ... > David L. Thompson The University of Montana > mailto:[EMAIL PROTECTED] Computer Science Department > http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 > Work Phone : (406)257-8530 >
Re: [opendx-dev] javadx shareable libraries
This is some of the stuff that libtool takes care of. It can take and put the appropriate information into the header of the library and binaries for linkages. In fact, this is how I noticed that the netcdf and other libraries need to have shareable versions installed when using javadx (libtool told me so.). If nothing else, I may add the libtool functionality just for the javadx branch of the tree. But I'd rather add full functionality right off the bat. One of the things that I'd like to have available while adding this functionality is a test set that I could build for checking validity of libs and executables. Do we have a module that would test a fair amount of the dxlibs when linked in as an inboard, outboard, and loadable and executed from a script? I already have the autoconf stuff set up for most platforms for a loadable and to add the functionality for outboard and inboard shouldn't take too much. Something that would require DXlite and libDX might be good. (On that thread, is there a chance that libDX could be broken into two libraries? DXlite and OtherDX? If they were shareable, then libDX wouldn't have to be so big.) Can someone send me a good dx-link program that could test the DXL library? (Why does the shareable code with javadx only link to a subset of DXL?) Opinions, suggestions? David 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 . David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
Re: [opendx-dev] javadx shareable libraries
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
Re: [opendx-dev] javadx shareable libraries
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
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
Re: [opendx-dev] javadx shareable libraries
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
RE: [opendx-dev] javadx shareable libraries
> Suhaib, since I haven't compiled stuff for Windows, what > is your take on > using libtool? Does it solve or create problems? David, It actually helps. libtool support for DX had been on my since for several months. I would like to add libtool support the way I discussed a few times on the opendx-dev list. Lately, I am flooded with work. We are redoing whole intarnet and internet and adding firewalls. Since company's network is under my control, this sudden decision of our directors to add firewalls is keeping me busy. I had 4.0.10 for linux (Red Hat 6.x) with OSF/MOTIF ready for users. Just do no get time to write a ReadMe file and upload it to your server. For windows, I have the following on plan. 1) add --export-dynamic support because the Cygwin v 1.1 (latest vesion) now support -shared and --export-dnamic 2) Build all the libs as sharebale for improved performance using libtools. 3) fix the scandir problems. It maybe a few weeks I would be able to start working on Windows version. Suhaib > > 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 >
[opendx-dev] javadx shareable libraries
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
