>Are you trying to link object files compiled without -fPIC into a shared >library? That would never work; -fPIC is required for all objects in shared >libraries.
I'm guessing so - I want to do it too! Or rather, be able to make a static library containing objects that can be linked to create a shared library - I think some people call it a 'convenience library'. If you are building a number of dynamic libraries and some sources are common - and you don't want to ship them in their own dynamic library - then its useful. It can also just be used to keep the source tree and its sub-projects nicely modular. And it can be used to work around insanely long command lines for linkers etc - I think libgcj uses them like this (and last time I tried, it fell foul of the command line length limit on FreeBSD if you didn't, though that was a little while ago). I don't think its an odd thing to do. Example: suppose I have a C++ library that I'll build as a DLL that wraps zlib, expat, and pcre. PoCo does this, in fact, using copies of sources from those libraries in the PoCo tree. The resulting DLL does not expose the normal exports for those libraries though - they are private. It would be nice to be able to build (with CMake) the zlib, expat and pcre libraries so that they can be kept seperate, and yet built into the DLL without creating exports, as the PoCo build does now. James _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
