Quantcast

Shared libraries cannot be found after deploying a CPack package

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Shared libraries cannot be found after deploying a CPack package

Frank Stappers
With the help of CPack we would like to make packages. Currently,
we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
STGZ, GZ). For static builds (so no shared libraries) these packages
can be deployed in any directory, without any problems. For builds that
use shared libraries, the binaries inside the packages do not seem to
work, if they are deployed in a path other than the $CMAKE_INSTALL_PREFIX.

When inspecting the RPATH's binaries, they all point to the
CMAKE_INSTALL_RPATH (${CMAKE_INSTALL_PREFIX}/lib/mcrl2) where
the libraries can be found. For RPMs and DEBs, that have a fixed
deployment path, this will not be a problem. We simply
set the CMAKE_INSTALL_PREFIX to the path where we want to the deploy the
package and the problem is "solved".

Deploying DMG, STGZ and GZ packages turns to be a bit more problematic,
because a user is free to chose a custom deployment path (which is most
likely not the ${CMAKE_INSTALL_PREFIX}$). As a result, all binaries that
use shared libraries cannot be executed, because they point to
non-existing paths.

So the question is as follows: Is it possible for CPack to create
packages that can be installed in a directory that deviates from
the $CMAKE_INSTALL_PREFIX? If so, which variables/modules do I need
set/execute?

Thanks in advance for any help,
Frank Stappers







_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Eric Noulard
2009/7/15 Frank Stappers <[hidden email]>:
> With the help of CPack we would like to make packages. Currently,
> we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
> STGZ, GZ). For static builds (so no shared libraries) these packages
> can be deployed in any directory, without any problems. For builds that
> use shared libraries, the binaries inside the packages do not seem to
> work, if they are deployed in a path other than the $CMAKE_INSTALL_PREFIX.

This depends on how you configured RPATH handling with CMake:

Did you read the different way to handle RPATH with CMake?
http://www.cmake.org/Wiki/CMake_RPATH_handling

> So the question is as follows: Is it possible for CPack to create
> packages that can be installed in a directory that deviates from
> the $CMAKE_INSTALL_PREFIX? If so, which variables/modules do I need
> set/execute?

This is not really a CPack problem, CPack is "only"
callind the "install" rule built by CMake
which may include relink (see previous ref).

Then if ever you build without RPATH then it becomes the
specific generator problem. It will have to either:

 1) relink to setup proper RPATH at **installation time**
     (no CPack any more at that time)

2) setup again  **at install time**
     some LD_LIBRARY_PATH, /etc/ld.so.conf.d/*
     or any mean that modify the dynamic library path
     on the target system (user or system-wide)

Dumb installer like TGZ and GZ and the like do not include
post-install steps which would make this possible.
Smarter one like RPM or DEB may be used to launch
post-install scripts which may accomplish such tasks.

There is a patch pending for post/pre install script
support for CPack RPM
http://public.kitware.com/Bug/view.php?id=8988


--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Hendrik Sattler
In reply to this post by Frank Stappers
Am Mittwoch 15 Juli 2009 17:20:25 schrieb Frank Stappers:

> With the help of CPack we would like to make packages. Currently,
> we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
> STGZ, GZ). For static builds (so no shared libraries) these packages
> can be deployed in any directory, without any problems. For builds that
> use shared libraries, the binaries inside the packages do not seem to
> work, if they are deployed in a path other than the $CMAKE_INSTALL_PREFIX.
>
> When inspecting the RPATH's binaries, they all point to the
> CMAKE_INSTALL_RPATH (${CMAKE_INSTALL_PREFIX}/lib/mcrl2) where
> the libraries can be found. For RPMs and DEBs, that have a fixed
> deployment path, this will not be a problem. We simply
> set the CMAKE_INSTALL_PREFIX to the path where we want to the deploy the
> package and the problem is "solved".
>
> Deploying DMG, STGZ and GZ packages turns to be a bit more problematic,
> because a user is free to chose a custom deployment path (which is most
> likely not the ${CMAKE_INSTALL_PREFIX}$). As a result, all binaries that
> use shared libraries cannot be executed, because they point to
> non-existing paths.
>
> So the question is as follows: Is it possible for CPack to create
> packages that can be installed in a directory that deviates from
> the $CMAKE_INSTALL_PREFIX? If so, which variables/modules do I need
> set/execute?
>
> Thanks in advance for any help,

You could force the RPATH to something like documented in the ld.so manpage
(linux):
$ORIGIN
ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath
specification to mean the directory containing  the  application  executable.  
Thus,  an application located in somedir/app could be compiled with gcc -Wl,-
rpath,’$ORIGIN/../lib’ so that it finds an associated shared library in
somedir/lib no matter where somedir is located in the directory hierarchy.

HS



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Frank Stappers
Hendrik Sattler wrote:

> Am Mittwoch 15 Juli 2009 17:20:25 schrieb Frank Stappers:
>> With the help of CPack we would like to make packages. Currently,
>> we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
>> STGZ, GZ). For static builds (so no shared libraries) these packages
>> can be deployed in any directory, without any problems. For builds that
>> use shared libraries, the binaries inside the packages do not seem to
>> work, if they are deployed in a path other than the $CMAKE_INSTALL_PREFIX.
>>
>> When inspecting the RPATH's binaries, they all point to the
>> CMAKE_INSTALL_RPATH (${CMAKE_INSTALL_PREFIX}/lib/mcrl2) where
>> the libraries can be found. For RPMs and DEBs, that have a fixed
>> deployment path, this will not be a problem. We simply
>> set the CMAKE_INSTALL_PREFIX to the path where we want to the deploy the
>> package and the problem is "solved".
>>
>> Deploying DMG, STGZ and GZ packages turns to be a bit more problematic,
>> because a user is free to chose a custom deployment path (which is most
>> likely not the ${CMAKE_INSTALL_PREFIX}$). As a result, all binaries that
>> use shared libraries cannot be executed, because they point to
>> non-existing paths.
>>
>> So the question is as follows: Is it possible for CPack to create
>> packages that can be installed in a directory that deviates from
>> the $CMAKE_INSTALL_PREFIX? If so, which variables/modules do I need
>> set/execute?
>>
>> Thanks in advance for any help,
>
> You could force the RPATH to something like documented in the ld.so manpage
> (linux):
> $ORIGIN
> ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath
> specification to mean the directory containing  the  application  executable.  
> Thus,  an application located in somedir/app could be compiled with gcc -Wl,-
> rpath,’$ORIGIN/../lib’ so that it finds an associated shared library in
> somedir/lib no matter where somedir is located in the directory hierarchy.
>
> HS

Thanks for the provided solution.
Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
problem, as the binaries are located in "${CMAKE_INSTALL_PREFIX}/bin/mcrl2".

Frank Stappers
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Michael Wild

On 16. Jul, 2009, at 9:26, Frank Stappers wrote:

> Hendrik Sattler wrote:
>> Am Mittwoch 15 Juli 2009 17:20:25 schrieb Frank Stappers:
>>> With the help of CPack we would like to make packages. Currently,
>>> we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
>>> STGZ, GZ). For static builds (so no shared libraries) these packages
>>> can be deployed in any directory, without any problems. For builds  
>>> that
>>> use shared libraries, the binaries inside the packages do not seem  
>>> to
>>> work, if they are deployed in a path other than the  
>>> $CMAKE_INSTALL_PREFIX.
>>>
>>> When inspecting the RPATH's binaries, they all point to the
>>> CMAKE_INSTALL_RPATH (${CMAKE_INSTALL_PREFIX}/lib/mcrl2) where
>>> the libraries can be found. For RPMs and DEBs, that have a fixed
>>> deployment path, this will not be a problem. We simply
>>> set the CMAKE_INSTALL_PREFIX to the path where we want to the  
>>> deploy the
>>> package and the problem is "solved".
>>>
>>> Deploying DMG, STGZ and GZ packages turns to be a bit more  
>>> problematic,
>>> because a user is free to chose a custom deployment path (which is  
>>> most
>>> likely not the ${CMAKE_INSTALL_PREFIX}$). As a result, all  
>>> binaries that
>>> use shared libraries cannot be executed, because they point to
>>> non-existing paths.
>>>
>>> So the question is as follows: Is it possible for CPack to create
>>> packages that can be installed in a directory that deviates from
>>> the $CMAKE_INSTALL_PREFIX? If so, which variables/modules do I need
>>> set/execute?
>>>
>>> Thanks in advance for any help,
>>
>> You could force the RPATH to something like documented in the ld.so  
>> manpage
>> (linux):
>> $ORIGIN
>> ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in  
>> an rpath
>> specification to mean the directory containing  the  application  
>> executable.
>> Thus,  an application located in somedir/app could be compiled with  
>> gcc -Wl,-
>> rpath,’$ORIGIN/../lib’ so that it finds an associated shared  
>> library in
>> somedir/lib no matter where somedir is located in the directory  
>> hierarchy.
>>
>> HS
>
> Thanks for the provided solution.
> Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
> problem, as the binaries are located in "${CMAKE_INSTALL_PREFIX}/bin/
> mcrl2".
>

On Mac you can set the INSTALL_NAME_DIR property (or the  
CMAKE_INSTALL_NAME_DIR variable) to something starting with  
@executable_path, to the same effect as above.

Michael

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Hendrik Sattler
Zitat von Michael Wild <[hidden email]>:
>> Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
>> problem, as the binaries are located in "${CMAKE_INSTALL_PREFIX}/bin/mcrl2".
>>
>
> On Mac you can set the INSTALL_NAME_DIR property (or the
> CMAKE_INSTALL_NAME_DIR variable) to something starting with
> @executable_path, to the same effect as above.

So maybe the proper value can be made available as variable? Or direct  
support in cmake with some boolean variable?
Like:
CMAKE_RELATIVE_RPATH_SUPPORTED true/false
CMAKE_RELATIVE_RPATH_PREFIX:
   Linux: "$ORIGIN"
   MacOS: "@executable_path"

Anything else?

HS


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Eric Noulard
2009/7/16 Hendrik Sattler <[hidden email]>:

> Zitat von Michael Wild <[hidden email]>:
>>>
>>> Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
>>> problem, as the binaries are located in
>>> "${CMAKE_INSTALL_PREFIX}/bin/mcrl2".
>>>
>>
>> On Mac you can set the INSTALL_NAME_DIR property (or the
>> CMAKE_INSTALL_NAME_DIR variable) to something starting with
>> @executable_path, to the same effect as above.
>
> So maybe the proper value can be made available as variable? Or direct
> support in cmake with some boolean variable?

Small message to say that I would find this a good feature request.

> Like:
> CMAKE_RELATIVE_RPATH_SUPPORTED true/false
> CMAKE_RELATIVE_RPATH_PREFIX:
>  Linux: "$ORIGIN"
>  MacOS: "@executable_path"
> Anything else?

May be there is some equivalent on Windows platform too
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
[just pointing the link, I'm really no windows expert and ....
 don't want to become one :-) ]

May be worth a Wiki update too (even before the feature is
requested/implemented)
http://www.cmake.org/Wiki/CMake_RPATH_handling

--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Michael Wild

On 16. Jul, 2009, at 14:45, Eric Noulard wrote:

> 2009/7/16 Hendrik Sattler <[hidden email]>:
>> Zitat von Michael Wild <[hidden email]>:
>>>>
>>>> Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
>>>> problem, as the binaries are located in
>>>> "${CMAKE_INSTALL_PREFIX}/bin/mcrl2".
>>>>
>>>
>>> On Mac you can set the INSTALL_NAME_DIR property (or the
>>> CMAKE_INSTALL_NAME_DIR variable) to something starting with
>>> @executable_path, to the same effect as above.
>>
>> So maybe the proper value can be made available as variable? Or  
>> direct
>> support in cmake with some boolean variable?
>
> Small message to say that I would find this a good feature request.
>
>> Like:
>> CMAKE_RELATIVE_RPATH_SUPPORTED true/false
>> CMAKE_RELATIVE_RPATH_PREFIX:
>>  Linux: "$ORIGIN"
>>  MacOS: "@executable_path"
>> Anything else?

Honestly, I don't think this is necessary. What is so complicated  
about this?

set(CMAKE_INSTALL_NAME_DIR "@executable_prefix/../lib")
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")

>
> May be there is some equivalent on Windows platform too
> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
> [just pointing the link, I'm really no windows expert and ....
> don't want to become one :-) ]

Seriously, that platform is just plain broken if you ask me.  
__declspec(dllimport), __declspec(dllexport)?! What were they  
thinking? And DLL-exported C++ template instantiations with member  
templates simply don't work. Sometimes I marvel at why so many people  
go trough the pains of writing software for such a broken system...

>
> May be worth a Wiki update too (even before the feature is
> requested/implemented)
> http://www.cmake.org/Wiki/CMake_RPATH_handling

ACK

Michael
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Eric Noulard
2009/7/16 Michael Wild <[hidden email]>:
>>
>> May be there is some equivalent on Windows platform too
>> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
>> [just pointing the link, I'm really no windows expert and ....
>> don't want to become one :-) ]
>
> Seriously, that platform is just plain broken if you ask me.
> __declspec(dllimport), __declspec(dllexport)?! What were they thinking?

Visibility control in shared libs may not be considered as evil,
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


> And
> DLL-exported C++ template instantiations with member templates simply don't
> work. Sometimes I marvel at why so many people go trough the pains of
> writing software for such a broken system...

This is another story :-)


--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Andreas Pakulat-2
On 16.07.09 15:26:16, Eric Noulard wrote:

> 2009/7/16 Michael Wild <[hidden email]>:
> >>
> >> May be there is some equivalent on Windows platform too
> >> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
> >> [just pointing the link, I'm really no windows expert and ....
> >> don't want to become one :-) ]
> >
> > Seriously, that platform is just plain broken if you ask me.
> > __declspec(dllimport), __declspec(dllexport)?! What were they thinking?
>
> Visibility control in shared libs may not be considered as evil,
> 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

GCC visibility is only half of the broken system that Microsoft
invented. It only declares what symbols should be visible when linking
to the library, but msvc even forces the user of a library to explain to
the linker which symbols he wants to use (the dllimport stuff). Thats
plain broken, the linker should be able to figure that out himself - ld
does it.

Andreas

--
Your analyst has you mixed up with another patient.  Don't believe a
thing he tells you.
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Michael Wild
In reply to this post by Eric Noulard

On 16. Jul, 2009, at 15:26, Eric Noulard wrote:

> 2009/7/16 Michael Wild <[hidden email]>:
>>>
>>> May be there is some equivalent on Windows platform too
>>> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
>>> [just pointing the link, I'm really no windows expert and ....
>>> don't want to become one :-) ]
>>
>> Seriously, that platform is just plain broken if you ask me.
>> __declspec(dllimport), __declspec(dllexport)?! What were they  
>> thinking?
>
> Visibility control in shared libs may not be considered as evil,
> 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. 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.

Just my 2 cents.

>
>
>> And
>> DLL-exported C++ template instantiations with member templates  
>> simply don't
>> work. Sometimes I marvel at why so many people go trough the pains of
>> writing software for such a broken system...
>
> This is another story :-)
>
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Michael Wild
In reply to this post by Andreas Pakulat-2

On 16. Jul, 2009, at 15:39, Andreas Pakulat wrote:

> On 16.07.09 15:26:16, Eric Noulard wrote:
>> 2009/7/16 Michael Wild <[hidden email]>:
>>>>
>>>> May be there is some equivalent on Windows platform too
>>>> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
>>>> [just pointing the link, I'm really no windows expert and ....
>>>> don't want to become one :-) ]
>>>
>>> Seriously, that platform is just plain broken if you ask me.
>>> __declspec(dllimport), __declspec(dllexport)?! What were they  
>>> thinking?
>>
>> Visibility control in shared libs may not be considered as evil,
>> 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
>
> GCC visibility is only half of the broken system that Microsoft
> invented. It only declares what symbols should be visible when linking
> to the library, but msvc even forces the user of a library to  
> explain to
> the linker which symbols he wants to use (the dllimport stuff). Thats
> plain broken, the linker should be able to figure that out himself -  
> ld
> does it.
>

Problem is, their broken binary format requires to know at _COMPILE_  
time that a symbol will be linked from a DLL. Nothing the linker can  
do about, really... At least as far as I understand it, but then I'm  
not sure MS understands it themselves.

Hell, ever had a look at windows.h and the stuff it includes? Gives  
you the creeps!

Michael

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Eric Noulard
In reply to this post by Michael Wild
2009/7/16 Michael Wild <[hidden email]>:
>> 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...


--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Michael Wild

On 16. Jul, 2009, at 15:46, Eric Noulard wrote:

> 2009/7/16 Michael Wild <[hidden email]>:
>>> 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

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Bill Hoffman
Michael Wild wrote:

>
> Actually, I'm planning on doing this with the .def files. But then,
> maintaining them might also become a nightmare.
>

You can generate them if you use dumpbin and some scripting....  But, it
is much easier to just use the declspec stuff....

-Bill
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Michael Wild

On 16. Jul, 2009, at 16:17, Bill Hoffman wrote:

> Michael Wild wrote:
>
>> Actually, I'm planning on doing this with the .def files. But then,  
>> maintaining them might also become a nightmare.
>
> You can generate them if you use dumpbin and some scripting....  
> But, it is much easier to just use the declspec stuff....
>
> -Bill

Only thing is, how do I find the files which need exporting/importing?  
I have 5000 source/header files, many of which do not export a single  
symbol, because they contain pure template code.

Probably I'll do some scripting (at least for the first conversion)  
which searches through all the .obj files and uses dumpbin to  
determine whether the corresponding source file exports something.  
Then I could try to demangle the name and print it along with the  
source file name into a file.

Michael
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Timothy M. Shead
Michael Wild wrote:

> On 16. Jul, 2009, at 16:17, Bill Hoffman wrote:
>
>> Michael Wild wrote:
>>
>>> Actually, I'm planning on doing this with the .def files. But then,  
>>> maintaining them might also become a nightmare.
>> You can generate them if you use dumpbin and some scripting....  
>> But, it is much easier to just use the declspec stuff....
>>
>> -Bill
>
> Only thing is, how do I find the files which need exporting/importing?  
> I have 5000 source/header files, many of which do not export a single  
> symbol, because they contain pure template code.
>
> Probably I'll do some scripting (at least for the first conversion)  
> which searches through all the .obj files and uses dumpbin to  
> determine whether the corresponding source file exports something.  
> Then I could try to demangle the name and print it along with the  
> source file name into a file.

Here is a tool (developed by others) that our project uses for this purpose:

http://k3d.hg.sourceforge.net/hgweb/k3d/file/079fa1503f31/gendef

Cheers,
Tim

--
Timothy M. Shead
Data Analysis & Visualization (1424)
Sandia National Laboratories
505-284-0139

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Shared libraries cannot be found after deploying a CPack package

Timothy M. Shead
Timothy M. Shead wrote:

> Michael Wild wrote:
>> On 16. Jul, 2009, at 16:17, Bill Hoffman wrote:
>>
>>> Michael Wild wrote:
>>>
>>>> Actually, I'm planning on doing this with the .def files. But then,  
>>>> maintaining them might also become a nightmare.
>>> You can generate them if you use dumpbin and some scripting....  
>>> But, it is much easier to just use the declspec stuff....
>>>
>>> -Bill
>> Only thing is, how do I find the files which need exporting/importing?  
>> I have 5000 source/header files, many of which do not export a single  
>> symbol, because they contain pure template code.
>>
>> Probably I'll do some scripting (at least for the first conversion)  
>> which searches through all the .obj files and uses dumpbin to  
>> determine whether the corresponding source file exports something.  
>> Then I could try to demangle the name and print it along with the  
>> source file name into a file.
>
> Here is a tool (developed by others) that our project uses for this purpose:
>
> http://k3d.hg.sourceforge.net/hgweb/k3d/file/079fa1503f31/gendef

Forgot to mention, here is how we call the gendef executable from CMake:

http://k3d.hg.sourceforge.net/hgweb/k3d/file/079fa1503f31/cmake/modules/K3DGenerateDEF.cmake

Cheers,
Tim


--
Timothy M. Shead
Data Analysis & Visualization (1424)
Sandia National Laboratories
505-284-0139

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Loading...