How to enforce export *to* a dynamic library?

Andreas Feldner pelzi at flying-snail.de
Thu Nov 21 21:08:53 GMT 2002


Hi,

I have a program that provides sort of a 'framework' to a sort of simple 
'plugins' each consisting of a .so library, loaded at runtime. The specific 
problem about this constellation is, that, unlike normal libraries, these 
plugin libraries don't provide any symbols themselves (apart from the 
initialisation routine), but use classes from the framework.

Now, some of these classes are exclusively used by the plugins, not the 
framework. The normal linker behaviour is to leave out any compile units that 
are not used. For me, it has to include everything.

I sort of made things work in the following way, and perhaps someone can tell 
me how to do it properly ;-)

To force linking of all classes of the 'framework' into the executable, I 
created a dummy routine (in a compile unit used by the exectuable) that 
referenced at least one method of everything else needed by the plugins.

In addition, I added the -E (-export-dynamic) flag to the linker stage. 
Actually here I hit another pitfall, as I had to write -Wl,-E into KDevelop's 
Project Settings/Compiler settings/Linker switches input field, as the -E 
flag would have been fed to g++; i.e. somehow libtool missed to insert the 
necessary '-Wl,' required for my setup and I don't know how to tell it to put 
it in.

I would assume that the correct way to cure my problem was to build the 
classes for the plugins as a (static) library (it is actually), and put 
'--whole-archive' in front of it during the link stage, and, probably 
'--no-whole-archive' after. I didn't find a way to achive this. I wrote these 
flags into the relevant Makefile.am's library list, but then 
autoconf/automake moans that I should put it into LD_FLAGS. If I put it 
there, the flag is at the very beginning of the link command, leading to a 
desastrous accumulation of doubly defined symbols from everywhere out of 
standard and base libraries I never heard of before.

Any hints? Perhaps just a reference to a good overview guide on 
autoconf/automake? ;-)

Cheers,
Andreas.

-- 
Andreas Feldner

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop mailing list