[CMake] Shared libraries cannot be found after deploying a CPack package
Michael Wild
themiwi at gmail.com
Thu Jul 16 09:51:34 EDT 2009
On 16. Jul, 2009, at 15:46, Eric Noulard wrote:
> 2009/7/16 Michael Wild <themiwi at gmail.com>:
>>> GCC even supports that feature:
>>>
>>> http://gcc.gnu.org/wiki/Visibility
>>>
>>> in particular you may read "2.2 Export Control" in
>>> http://people.redhat.com/drepper/dsohowto.pdf
>>
>> I don't say that this is evil. I only say that REQUIRING it is
>> really bad.
>
> OK I missed that point.
>
>> It breaks perfectly valid, standard-compliant code... Now, if the
>> MSVC
>> compiler offered an option to export all symbols by default (as
>> mingw-gcc
>> does), it would be a different story. But introducing stuff like
>>
>> #ifdef SUPERLIB_EXPORTS
>> # define SUPERLIB_API __declspec(dllexport)
>> #else
>> # define SUPERLIB_API __declspec(dllimport)
>> #endif
>>
>> into a code with roughly 5000 source files (many of which contain
>> complicated templates, so figuring out where to actually put these
>> SUPERLIB_API things is not trivial), from which 60 DLL's should be
>> built, is
>> just very painful.
>
> OK and I do fully agree with.
> I did this for porting a C++ code on WIn32 and it was painfull even
> for far less files and DLL.
> Note that theoretically you may specify the export/import rules in a
> separate .def file
>
> http://msdn.microsoft.com/en-us/library/28d6s79h(VS.71).aspx
> http://msdn.microsoft.com/en-us/library/d91k01sh(VS.80).aspx
>
> However I did not have enoough time to do it this way so I did
> go for the #ifdef etc...
>
Actually, I'm planning on doing this with the .def files. But then,
maintaining them might also become a nightmare.
Michael
More information about the CMake
mailing list