On Tue, Feb 01, 2005 at 01:09:26PM +0100, Miriam Ruiz wrote: > If I can not put that .so inside the package, the other solution > might be getting 3 packages from maserver: libmaserver, > libmaserver-dev and maserver itself. libmaserver would have the > shared library and libmaserver-dev the header files to make new > plugins. Would that be better? I guess that's what is suggested (err, recommended:). Did you try Steve's suggestion?
If I understand correctly, he intends that the entire library is included in the executable, but nowhere else. Then, when the executable dlopen()s a plugin .so, all the symbols are already statically linked into the exe and don't depend on any library. Thus, the library isn't even installed, and there is no wasted space. I haven't done dynamic post-initialization linking, so my understanding may be wrong. What you should probably do is to list each of the object files during the compilation (linking) of the executable. Then, each of those files will be included in entirety. If, instead, you link with the library which contains those objects, then only the symbols necessary *for the executable* will be included, and some may be necessary for the plugins, but not the exe. You might find -Wl,--whole-archive useful, though its use is mostly discouraged (it allows you to created shared libraries from static ones, but only on certain platforms; and, shared libraries are supposed to be PIC, and static ones are supposed to be non PIC). gcc passes -Wl commands on to the linker (ld). Read the ld manpage (in particular, make sure you have a corresponding -Wl,--no-whole-archive). > > Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
