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
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 easie
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
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
__
On 16. Jul, 2009, at 15:46, Eric Noulard wrote:
2009/7/16 Michael Wild :
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 REQUIR
2009/7/16 Michael Wild :
>> 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
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 :
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
On 16. Jul, 2009, at 15:26, Eric Noulard wrote:
2009/7/16 Michael Wild :
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 :-) ]
Serious
On 16.07.09 15:26:16, Eric Noulard wrote:
> 2009/7/16 Michael Wild :
> >>
> >> 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
2009/7/16 Michael Wild :
>>
>> 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 broke
On 16. Jul, 2009, at 14:45, Eric Noulard wrote:
2009/7/16 Hendrik Sattler :
Zitat von Michael Wild :
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 prope
2009/7/16 Hendrik Sattler :
> Zitat von Michael Wild :
>>>
>>> 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_N
Zitat von Michael Wild :
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
@executab
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
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
>>
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 direct
2009/7/15 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
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, t
18 matches
Mail list logo
