On Mon, 10 Apr 2000, Kevin Atkinson wrote:
> On Mon, 10 Apr 2000, Bob Friesenhahn wrote:
>
> > Regarding your Problem 2, the way the library I maintain (ImageMagick,
> > http://www.imagemagick.org) does it, each module exposes unique
> > symbols using a pre-defined naming scheme so that the module loader
> > computes the correct name for symbol in the module. Only one symbol
> > needs to be loaded. The rest of the symbols are registered via
> > call-back from the module itself. This eliminates any need for the
> > pre-loading complexity. The library has 72 modules. I doubt that the
> > command line can reliably pass enough parameters to handle libtool's
> > preload requirement for 72 modules.
>
> I basically do the same thing. But I need to be able to get the modules
> loaded some how. How do you do if they can't be loaded using dlopen and
> friends.....
I should have mentioned that when these objects are not loaded as
modules, they are included in a larger shared or static library via
the magic of Automake conditionals. There is a small fragment of
conditional code which comes into effect when the modules are included
as objects in the larger library, which serves to invoke their
registration routines. This means that there is very little source
difference between the module version and the library version.
> The basic problem is that on many platforms the C++ libraries are NOT
> compiled as static libraries (and often not compiled with pic
> support (which means they can't get linked into the shared modules) but
> they some how need to get access to the c++ libraries when loaded....
This is indeed annoying. Some configure-magic could identify the
problem. Then you would need some way to instruct libtool to build
the appropriate library.
Bob
======================================
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
