On Wednesday 15 October 2003 10:29, Rafael Laboissiere wrote:
| * Alan W. Irwin <airwin@...> [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
Nevertheless, the libtool manual says, and I
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
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.
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
# end of enable_dyndrivers
# 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?)
| 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