From: Per P. <per...@ma...> - 2003-10-14 10:40:03
|
Hi, sorry for jumping into this without actually having dug into the build=20= system of PLplot, but I'd just like to point out that the notion that shared implies dynamic and vice versa is=20= true on ELF-systems and certainly others but causes problems on OS X. In e.g. ELF systems the divide is between static and shared+dynamic=20 libs whereas on OS X the divide is between static+shared and dynamic. IMHO the best solution would be to separate the case into static,=20 shared and dynamic where the latter two defaults to the same actions=20 but may be changed on a per system basis. Hope this makes sense... /Per On Tuesday, October 14, 2003, at 01:02 AM, Jo=E3o Cardoso wrote: > > Hi, > > Although possible, it is not likely that any system has dynamic=20 > loading and > don't have shared libraries, or that a user wants dynamic drivers and=20= > don't > want dynamic libraries, so, why not: > > RCS file: /cvsroot/plplot/plplot/configure.ac,v > retrieving revision 1.108 > diff -r1.108 configure.ac > 463a464,467 >> if test "$enable_shared" !=3D "yes"; then >> enable_dyndrivers=3D"no" >> fi >> > > Recently I configured with --disable-shared, and forget to=20 > disable-dyndrivers, > and the result what a failed make. > > Do anybody foresee any problem with this? > > Joao |
From: <jc...@fe...> - 2003-10-14 17:26:15
|
On Tuesday 14 October 2003 09:47, Per Persson wrote: | Hi, | sorry for jumping into this without actually having dug into the build | system of PLplot, but I'd just like to | point out that the notion that shared implies dynamic and vice versa is | true on ELF-systems and certainly others but causes | problems on OS X. | In e.g. ELF systems the divide is between static and shared+dynamic | libs whereas on OS X the divide is between static+shared and dynamic. | | IMHO the best solution would be to separate the case into static, | shared and dynamic where the latter two defaults to the same actions | but may be changed on a per system basis. | | Hope this makes sense... I don't know if it makes. I think that it depends on the meaning of shared = and=20 dynamic. In linux, I can't build dynamic drivers with static libraries, i.e., if I=20 configure with a plain=20 ./configure --disable-shared I get a make error when trying to building the drivers. The error, that I don't have available anymore, is that "get-drv-info" can'= t=20 get symbol information from the recently build drivers, as they are=20 statically build and get-drv-info assumes they are dynamically build. Unless this doesn't happens in other systems, we should fix it. Does a system exists where a make succeeds if plplot is configured only wit= h=20 =2D-disable-shared (and the implicit --enable-dyndrivers)?=20 Or does a make succeeds with a plain "./configure" where "configure"=20 determines that the OS/compiler has no shared capabilities ( but the implic= it=20 =2D-enable-dyndrivers is still there)?=20 Joao | /Per | | On Tuesday, October 14, 2003, at 01:02 AM, Jo=E3o Cardoso wrote: | > Hi, | > | > Although possible, it is not likely that any system has dynamic | > loading and | > don't have shared libraries, or that a user wants dynamic drivers and | > don't | > want dynamic libraries, so, why not: | > | > RCS file: /cvsroot/plplot/plplot/configure.ac,v | > retrieving revision 1.108 | > diff -r1.108 configure.ac | > 463a464,467 | > | >> if test "$enable_shared" !=3D "yes"; then | >> enable_dyndrivers=3D"no" | >> fi | > | > Recently I configured with --disable-shared, and forget to | > disable-dyndrivers, | > and the result what a failed make. | > | > Do anybody foresee any problem with this? | > | > Joao | | ------------------------------------------------------- | This SF.net email is sponsored by: SF.net Giveback Program. | SourceForge.net hosts over 70,000 Open Source Projects. | See the people who have HELPED US provide better services: | Click here: http://sourceforge.net/supporters.php | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Per P. <per...@ma...> - 2003-10-14 20:13:06
|
OK, maybe I spoke too early... (again;-) These issues caused some grief for OS X users in octave some time ago=20 when dynamic loading of code modules (.oct) became conditioned on=20 shared libs being built, hence my reaction. > | On Tuesday, October 14, 2003, at 01:02 AM, Jo=E3o Cardoso wrote: > | > Although possible, it is not likely that any system has dynamic > | > loading and don't have shared libraries, or that a user wants > | > dynamic drivers and don't want dynamic libraries, so, why not: On OS X you can't load dynamically from a shared library. You load=20 dynamically from a "bundle", a completely different creature. A shared lib is used to link shared or statically(!) from. To further=20 complicate the matter, a shared lib is referred to as a dynamic library=20= (suffix .dylib) on OS X. Plain (.a) static libs exists too, but=20 libxxx.dylib will take precedence over libxxx.a for static linking. Libtool (CVS tag 1.5.0a (1.1220.2.33 2003/09/29 11:43:50)) is supposed=20= to mediate such differences, and actually seems to do the right thing... So, in conclusion, you are right. (slapping myself) Haven't done extensive testing though. /Per PS. This is probably good news wrt Libtool and shared libs for OS X. I=20= used libtool from CVS (tag 1.5.0a) and ./configure --disable-f77 --disable-python --disable-octave PPS. I'll probably look deeper into the matter later, since I'd like to=20= try out the octave bindings, just need to sort out a few other things=20 first. |
From: Alan W. I. <ai...@us...> - 2003-10-14 22:41:19
|
On 2003-10-14 18:24+0100 Jo=E3o Cardoso wrote: > In linux, I can't build dynamic drivers with static libraries, i.e., if I > configure with a plain > ./configure --disable-shared > I get a make error when trying to building the drivers. > > The error, that I don't have available anymore, is that "get-drv-info" ca= n't > get symbol information from the recently build drivers, as they are > statically build and get-drv-info assumes they are dynamically build. There is a useful technical discussion of the Linux loading issues at http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html. It's not advertised very much, but apparently for Linux, "dynamically loaded libraries" or plugins (a name I prefer which seems more appropriate to the dyndriver case) can actually just be compiled objects and don't have to be shared objects at all. (There is an example of this right in the howto.) S= o I think what Joao found is a bug in get-drv-info or the way we configure libtool for get-drv-info, and I will put it on my ToDo list for further investigation. However, I have little time now so I am hoping someone else will step in to investigate and fix the bug before I get to it. :-) Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-10-15 09:29:18
|
* Alan W. Irwin <ai...@us...> [2003-10-14 15:40]: > On 2003-10-14 18:24+0100 João Cardoso wrote: > > > In linux, I can't build dynamic drivers with static libraries, i.e., if I > > configure with a plain > > ./configure --disable-shared > > I get a make error when trying to building the drivers. > > > > The error, that I don't have available anymore, is that "get-drv-info" can't > > get symbol information from the recently build drivers, as they are > > statically build and get-drv-info assumes they are dynamically build. > > There is a useful technical discussion of the Linux loading issues at > http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html. It's not > advertised very much, but apparently for Linux, "dynamically loaded > libraries" or plugins (a name I prefer which seems more appropriate to the > dyndriver case) can actually just be compiled objects and don't have to be > shared objects at all. Where have you seen this information in the HOWTO? My understanding is that *.o objects cannot be dynamically linked, only *.so objects can (*.so are compiled with the -shared option in Linux). I may be wrong, but *.o and .so objects are quite different beasts: $ cd drivers/.libs $ file xfig*o xfig.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped xfig.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped -- Rafael |
From: Rafael L. <lab...@ps...> - 2003-10-15 10:48:56
|
* Rafael Laboissiere <lab...@ps...> [2003-10-15 11:29]: > Where have you seen this information in the HOWTO? My understanding is that > *.o objects cannot be dynamically linked, only *.so objects can (*.so are > compiled with the -shared option in Linux). I may be wrong, but *.o and .so > objects are quite different beasts: > > $ cd drivers/.libs > $ file xfig*o > xfig.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped > xfig.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped Indeed, if the *.so file is replaced by the *.o, the driver cannot be dynamically linked: # ( cd /usr/lib/plplot5.2.1/driversd/ ; cp xfig.so xfig.so-save ) # cd drivers/.libs # cp xfig.o /usr/lib/plplot5.2.1/driversd/xfig.so # cd ../../examples/c # make x01c > /dev/null # ./x01c -dev xfig Plplot library version: 5.2.1 Unable to load driver: xfig. *** PLPLOT ERROR *** Unable to load driver Program aborted # ( cd /usr/lib/plplot5.2.1/driversd/ ; mv xfig.so-save xfig.so ) -- Rafael |
From: Alan W. I. <ai...@us...> - 2003-10-15 15:17:54
|
On 2003-10-15 11:29+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ai...@us...> [2003-10-14 15:40]: > > There is a useful technical discussion of the Linux loading issues at > > http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html. It's not > > advertised very much, but apparently for Linux, "dynamically loaded > > libraries" or plugins (a name I prefer which seems more appropriate to the > > dyndriver case) can actually just be compiled objects and don't have to be > > shared objects at all. > > Where have you seen this information in the HOWTO? Forget my comment that there was an example. I misread something too fast. But the possibility is referred to, see quote from the howto below. > My understanding is that > *.o objects cannot be dynamically linked, only *.so objects can (*.so are > compiled with the -shared option in Linux). I may be wrong, but *.o and .so > objects are quite different beasts: > > $ cd drivers/.libs > $ file xfig*o > xfig.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped > xfig.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped True, but although the formats are completely different they both include the required symbol information so it is _possible_ this might work if dlopen is smart enough. Thus, I was intrigued by the following sentence that appeared in the above howto: "In Linux, DL libraries aren't actually special from the point-of-view of their format; they are built as standard object files or standard shared libraries as discussed above." If you look "above" in that howto, the only difference between object files that are included in shared libraries and object files that are included in static libraries is the -fPIC (of -fPic) option used for compiling position-independent code. I don't know whether or not that option is required in order to dlopen an object file, but if so we can certainly compile our drivers with that option. So my whole argument rests on that one sentence that you can dlopen object files as well as shared libraries in Linux. What's needed now is some simple hello.c type experiments with dlopen (keeping it really simple and avoiding libtool for now) to see whether that sentence above can be confirmed. Unfortunatley, I don't have time for that at the moment, but I will pursue it eventually because such technical challenges intrigure me. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-10-15 23:37:36
|
* Alan W. Irwin <ai...@us...> [2003-10-15 08:10]: > If you look "above" in that howto, the only difference between object files > that are included in shared libraries and object files that are included in > static libraries is the -fPIC (of -fPic) option used for compiling > position-independent code. I don't know whether or not that option is > required in order to dlopen an object file, but if so we can certainly > compile our drivers with that option. Try this: $ cd drivers $ make clean $ make xfig.la You will see lots of output from the libtool script, but here is the summary: gcc -c xfig.c -fPIC -o .libs/xfig.o gcc -shared .libs/xfig.o -o .libs/xfig.so (Notice that I removed most of the flags of the gcc commands.) The *.o object files for the drivers *_are_* compiled with the -fPIC option, but they cannot be dlopened, as I demonstrated in a previous post here. > So my whole argument rests on that one sentence that you can dlopen object > files as well as shared libraries in Linux. This is weak evidence. > What's needed now is some simple hello.c type experiments with dlopen > (keeping it really simple and avoiding libtool for now) to see whether that > sentence above can be confirmed. In Linux, without the -shared option, good luck! -- Rafael |
From: <jc...@fe...> - 2003-10-15 12:47:42
|
On Wednesday 15 October 2003 10:29, Rafael Laboissiere wrote: | * Alan W. Irwin <ai...@us...> [2003-10-14 15:40]: | > On 2003-10-14 18:24+0100 Jo=E3o Cardoso wrote: | > > In linux, I can't build dynamic drivers with static libraries, | > > i.e., if I configure with a plain | > > ./configure --disable-shared | > > I get a make error when trying to building the drivers. | > > | > > The error, that I don't have available anymore, is that | > > "get-drv-info" can't get symbol information from the recently | > > build drivers, as they are statically build and get-drv-info | > > assumes they are dynamically build. | > | > There is a useful technical discussion of the Linux loading issues | > at http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html. | > It's not advertised very much, but apparently for Linux, | > "dynamically loaded libraries" or plugins (a name I prefer which | > seems more appropriate to the dyndriver case) can actually just be | > compiled objects and don't have to be shared objects at all. There is definitively a problem of name convention here. And Per Persson=20 explanation of the OS X jargon didn't help :(. But I kind-of understood=20 it.=20 Nevertheless, the libtool manual says, and I <quote> 4-Dlopening a module, so that the application can resolve its own,=20 dynamically-computed references. If there is an error opening the=20 module, or the module is not found, then the application can recover=20 without crashing.=20 Libtool emulates `-dlopen' on static platforms by linking objects into=20 the program at compile time, and creating data structures that=20 represent the program's symbol table. </quote> If I understand it, and I think I do, in systems where only static=20 linking exists, libtool statically links the several object files (that=20 would otherwise be dynamically loaded objects) into the executable, and=20 arranges at run time to *simulate* ldopen() them. But this *simulation* seems a nonsense to me, because the developper=20 don't know what modules will be asked to be loaded for at run time! An=20 independ developper couldn't distribute a module without recompiling=20 the whole application! In our case, at build time, get-drv-info would need to be linked with=20 all drivers. And the plplot library also. This is nothing more than=20 static linking, so lets forget the simulation and link statically when=20 the user or libtool set --disable-shared. And this seems to be already done in drivers/Makefile.am, that has a=20 section=20 if enable_dyndrivers =2E.. # end of enable_dyndrivers else # start of static driver alternative which is implemented using # a convenience library to be included in libplplot. Thus, if --disable-shared is set, either by the user or by configure,=20 one should force --disable-dyndrivers. But I haven't followed the OS X or Cygwin threads, and don't know if,=20 nonetheless all my wisdom :), dyndrivers was actually build=20 simultaneously with static libraries. (They could be, as both Cyhwin/OS=20 X are *not* static platforms, but what is the point?) Joao | Where have you seen this information in the HOWTO? My understanding | is that *.o objects cannot be dynamically linked, only *.so objects | can (*.so are compiled with the -shared option in Linux). I may be | wrong, but *.o and .so objects are quite different beasts: | | $ cd drivers/.libs | $ file xfig*o | xfig.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 | (SYSV), not stripped xfig.so: ELF 32-bit LSB shared object, Intel | 80386, version 1 (SYSV), not stripped |
From: Alan W. I. <ai...@us...> - 2003-10-15 15:25:58
|
On 2003-10-15 13:45+0100 Jo=E3o Cardoso wrote: > Thus, if --disable-shared is set, either by the user or by configure, > one should force --disable-dyndrivers. You might well be right here. But the libtool documentation is notorious for being behind the moving target which is libtool development. So I think we need to do some simple experiments first with bare dlopen, then with libtool-1.5 before making a decision. As I explained elsewhere, I have no time at the moment to pursue this, but I am intrigued so I will eventually look into this. Please put something in the PROBLEMS file so we will be reminded to deal with this one way or the other before the next release. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ai...@us...> - 2003-10-16 01:08:49
|
On 2003-10-15 08:24-0700 Alan W. Irwin wrote: > So I think > we need to do some simple experiments first with bare dlopen, then > with libtool-1.5 before making a decision. Well, I could not restrain my curiosity so I went ahead with some investigation, and here are the results. My simple dlopen experiments convinced me that dlopening object files is not allowed in Linux (contrary to the Howto): gcc -shared -fPIC libhello.c -o libhello.so gcc -g -o demo_dynamic demo_dynamic.c -ldl ./demo_dynamic Hello, library world. So simple dlopen of shared object works as advertised. gcc -fPIC libhello.c -c -o libhello.so Couldn't open libhello.so: ./libhello.so: ELF file's phentsize not the expected size But simple dlopen of non-shared simple object file does not work. If you look up that error message on google, you see lots of discussion including this year 2000 thread: http://sources.redhat.com/ml/bug-glibc/2000-10/msg00031.html Apparently, you can do this on solaris, but the linux dlopen types don't want to implement this behaviour (at least that was the attitude in 2000). Now, as Joao noted, libtool has some solutions for platforms (e.g., Linux) where plugins cannot be object files. I tried to make that work (using libtool options like -dlopen self), but I couldn't do it for the simple test case I put together. I have run out of time for now and doubt I will try this again any time soon. Unless someone else wants to take over with their own libtool experiments, I guess we could just accept that the combination of --disable-shared and plug-ins is not well supported on our dominant platform (Linux) even under libtool for now (or else I could not find the right combination of options to make this work under libtool.) Given this, then as a semi-permanent workaround (at least until libtool can support it cross-platform) it makes sense to disable dyndrivers if shared libraries are disabled just like Joao has suggested all along. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-10-16 18:02:33
|
On Thursday 16 October 2003 02:07, Alan W. Irwin wrote: | On 2003-10-15 08:24-0700 Alan W. Irwin wrote: | > So I think | > we need to do some simple experiments first with bare dlopen, then | > with libtool-1.5 before making a decision. | | Well, I could not restrain my curiosity so I went ahead with some | investigation, and here are the results. | | My simple dlopen experiments convinced me that dlopening object files | is not allowed in Linux (contrary to the Howto): | | gcc -shared -fPIC libhello.c -o libhello.so | gcc -g -o demo_dynamic demo_dynamic.c -ldl | ./demo_dynamic | Hello, library world. | | So simple dlopen of shared object works as advertised. | | gcc -fPIC libhello.c -c -o libhello.so | Couldn't open libhello.so: ./libhello.so: ELF file's phentsize not | the expected size | | But simple dlopen of non-shared simple object file does not work. | | If you look up that error message on google, you see lots of | discussion including this year 2000 thread: | | http://sources.redhat.com/ml/bug-glibc/2000-10/msg00031.html | | Apparently, you can do this on solaris, but the linux dlopen types | don't want to implement this behaviour (at least that was the | attitude in 2000). | | Now, as Joao noted, libtool has some solutions for platforms (e.g., | Linux) where plugins cannot be object files. I tried to make that | work (using libtool options like -dlopen self), but I couldn't do it | for the simple test case I put together. | | I have run out of time for now and doubt I will try this again any | time soon. Unless someone else wants to take over with their own | libtool experiments, I guess we could just accept that the | combination of --disable-shared and plug-ins is not well supported on | our dominant platform (Linux) Have you seen the bugs report in the project homepage patches section? get-drv-info fails on HPUX for tkwin and tk drivers It seems that dl_lt*() is not doing its job under HPUX, that uses shl_load() instead of dl_open(). I think that we don't browse the patch, request, etc in our project page very often, and that is bad, as users get the impression that we are unresponsibles. I remember to read in another sf project that they have disabled that sourceforge features. Couldn't we do that also? Or at least put there a visible README.FIRST to redirect users to the mailing lists. Of course this is not as good, because users must register, which they might not want to do. Joao | even under libtool for now (or else I | could not find the right combination of options to make this work | under libtool.) Given this, then as a semi-permanent workaround (at | least until libtool can support it cross-platform) it makes sense to | disable dyndrivers if shared libraries are disabled just like Joao | has suggested all along. | | Alan | __________________________ | Alan W. Irwin | email: ir...@be... | phone: 250-727-2902 | | Astronomical research affiliation with Department of Physics and | Astronomy, University of Victoria (astrowww.phys.uvic.ca). | | Programming affiliations with the PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), | the Loads of Linux Links project (loll.sf.net), and the Linux | Brochure Project (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | This SF.net email is sponsored by: SF.net Giveback Program. | SourceForge.net hosts over 70,000 Open Source Projects. | See the people who have HELPED US provide better services: | Click here: http://sourceforge.net/supporters.php | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ai...@us...> - 2003-10-16 18:37:17
|
On 2003-10-16 19:00+0100 Jo=E3o Cardoso wrote: > It seems that dl_lt*() is not doing its job under HPUX, that uses > shl_load() instead of dl_open(). No time, and I think Rafael (the guy who really knows about libltdl and probably the one who should be responding) has the same problem for the nex= t few months. > > I think that we don't browse the patch, request, etc in our project page > very often., and that is bad, as users get the impression that we are > unresponsibles. I remember to read in another sf project that they have > disabled that sourceforge features. Couldn't we do that also. Or at > least put there a visible README.FIRST to redirect users to the mailing > lists. Good points. I don't think we want to disable those features, but we shoul= d state our preference to use the plplot_devel mailing list. Fortunately, there is a configuration you can do at SF for this, and I have just changed the preferred support to the plplot_devel list. The effects of this change are quite minor as far as I can see (a mention about 1/3rd down the page at http://sourceforge.net/support/getsupport.php?group_id=3D2915). However, fo= r what it is worth we can now claim our preference is documented. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |