Ladar Levison wrote: > Eugene Crosser wrote: >> I suspect that this may break on AMD64. It's more picky about PIC/non-PIC >> code >> (no pun intended), attempt to link objects from .a into .so often fails. >> > > I haven't tested this method on any AMD64 servers, but it wouldn't > surprise if you were right. When I tried using this method on a Cent OS > 5 system, I had to link 1-2 or other libraries before dlopen() would > accept it. > > Any thoughts on a better way of accomplishing the same task? I like to > combine all of the f/oss libraries my daemon uses into a single library > (clamav, openssl, memcached, etc). It makes deployments easier > (executable, f/oss library and config file).
Technically, you have to ensure that all the code that is going into your shared object is compiled with -fPIC. If the libraries where built with automake/libtool, the .so's are (obviously) made of PIC objects, while .a's are likely not. If you use automake/libtool to build *your* project, you specify library descriptors (.la files) in the build instructions in Makefile.am, and the infrastructure will do "The Right Thing" for you, taking either .a or .so libraries depending on your intended target. I think that the .so's are still dynamically linked in this case, and I am not sure if you can forcibly clump all the objects into a single .so. On the other hand, maybe you don't need. Sorry for being so vague. Automake and libtool documentation is where you can find definite answers. Eugene
signature.asc
Description: OpenPGP digital signature
_______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
