Beware of dependencies between shared objects. Let's assume 2 chunks of
core functionality are seperated off into say A.so and B.so. This will
work fine as long as there are no interdependencies between A.so and
B.so. Let's however assume A.so needs to call something in B.so. That
means before A.so is loaded B.so must already have been loaded for its
symbols to be available in order to be able to resolve the references to
them when A.so is opened. Also, on Solaris at least special flags must
be specified to dlopen to make symbols in B.so visible to the
subsequently dlopen'd A.so. The other way of doing this is to specify a
linker dependency between A.so and B.so, but that will effectively cause
B.so to be loaded as soon as A.so is loaded. In both these scenarios,
both .so files will end up loaded anyway, so it really seems fruitless
to seperate them.
The problem with this whole suggestion is that it will be very, very
easy to bring the whole edifice crashing down - one misplaced
cross-shared-object function call will result not in compile-time or
link-time errors, but in runtime linker errors. In some cases I'm sure
it is possible to seperate out some bits of the core so that they don't
depend on anything else, but I'm far from persuaded the overall benefit
will be worth the extra complications.
Alan Burlison
