On 10/27/05, Adam D. Bradley <[EMAIL PROTECTED]> wrote:
GNU ld has a "--whole-archive" flag that forces it to include all the contents of an archive (libcrystalspace.a ) in the linked binary instead of just picking the objects it needs... doesn't that address this issue a lot more (memory- and disk-) efficiently?
I don't know. Does that also publish all the symbols so that they can be seen by the loaded plugins, or does doing so require an additional flag.
"--export-dynamic" makes sure all of the symbols are exported for dynamic linking.
At any rate, overall, it turns out to be a bad idea in the long run. When I used to work on NextStep, the linking model worked the way you suggest, where the application was responsible for supplying the libraries needed for plugin modules. This turned out to be a major headache because application authors didn't always know the full set of libraries required by plugins; especially if the plugin API was extensible (as it is in CS), and plugins could be authored by outside sources. With MacOS/X, Apple adopted this scheme from NextStep, but found it so problematic that they finally abandoned it a few years ago in favor of having each module be responsible for its own library dependencies. From a maintenance standpoint, it's a big win.
I'm not sure the analogy holds (but am perfectly willing to admit I may be wrong). When it comes to external dependencies or inter-plugin dependencies, I agree completely. But I think libcrystalspace.a is (or at least, should be) more analogous to the C library - a "kernel" (forgive the mixing of metaphors) of primitives (everything under "lib/") that every CS component assumes, so it makes more sense to have that in one place (the base app) and let the plugins handle all of the other dependencies for themselves.
Plus, a quick and unscientific profile of the build process leads me to believe that not linking every plugin against a 50MB (debug) libcrystalspace.a would slash 25% off of the build time on my box, which is a not-insubstantial amount of time.
Anyhow, once we fully support shared libraries (libcrystalspace.so, etc.) in CS, that will effectively address the space issue (memory and disk).
Agreed, that's the "right" solution anyway :-)
Adam
|
-- Adam D. Bradley <[EMAIL PROTECTED]> Boston University Dept. of Computer Science |
signature.asc
Description: This is a digitally signed message part
