Hello, the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled? I think this would be really important because this compiler switch changes the abi and for that programs can crash. I think that a lot of people disable it already in their own programs, but may be they don't compile the boost libraries with this switch... Any comments? Regards Hansjörg
On Tue, Feb 10, 2009 at 9:44 AM, Hansi <hansipet@web.de> wrote:
Hello,
the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled? I think this would be really important because this compiler switch changes the abi and for that programs can crash. I think that a lot of people disable it already in their own programs, but may be they don't compile the boost libraries with this switch...
Any comments?
I haven't followed previous discussions on this, but I think _SECURE_SCL could be the default for debug builds. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled? I think this would be really important because this compiler switch changes the abi and for that programs can crash. I think that a lot of people disable it already in their own programs, but may be they don't compile the boost libraries with this switch...
Any comments?
IMHO _SECURE_SCL should participate in the library name mangling. I collected the previous discussions on this a few months ago: http://lists.boost.org/boost-users/2008/10/41253.php
Jean-Francois Bastien schrieb:
IMHO _SECURE_SCL should participate in the library name mangling.
I collected the previous discussions on this a few months ago: http://lists.boost.org/boost-users/2008/10/41253.php
I think also that it is important that it is inside the name! Really important to avoid any bugs!
Hansi skrev:
Hello,
the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled?
Yes. I define import feature ; # # Composite feaure that ensures <define> can propagate # to all dependencies, not just sub-projects. # feature.feature secure-stl : on off : propagated composite optional ; feature.compose <secure-stl>off : <define>_SECURE_SCL=0 <define>_CRT_SECURE_NO_DEPRECATE=1 <define>_SCL_SECURE_NO_DEPRECATE=1 <define>_CRT_NONSTDC_NO_DEPRECATE=1 ; And then add <secure-stl>off to the requirements. I am in favor of libraries being named differently, eg. with "_nsc" suffix. -Thorsten
On Thu, Feb 12, 2009 at 3:07 AM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Hansi skrev:
Hello,
the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled?
Yes. I define
import feature ;
# # Composite feaure that ensures <define> can propagate # to all dependencies, not just sub-projects. #
feature.feature secure-stl : on off : propagated composite optional ; feature.compose <secure-stl>off : <define>_SECURE_SCL=0 <define>_CRT_SECURE_NO_DEPRECATE=1 <define>_SCL_SECURE_NO_DEPRECATE=1 <define>_CRT_NONSTDC_NO_DEPRECATE=1 ;
And then add
<secure-stl>off
to the requirements.
I am in favor of libraries being named differently, eg. with "_nsc" suffix.
Oh please yes. I always compile boost with secure_scl and a few others things disabled (or some of my programs take exponentially longer to run). Having name-mangled libraries for having those enabled or disabled would be perfect.
On Fri, Feb 13, 2009 at 3:32 PM, OvermindDL1 <overminddl1@gmail.com> wrote:
On Thu, Feb 12, 2009 at 3:07 AM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Hansi skrev:
Hello,
the problem with _SECURE_SCL define was already discussed a few times on this list. But til now it came never to a end. Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled?
Yes. I define
import feature ;
# # Composite feaure that ensures <define> can propagate # to all dependencies, not just sub-projects. #
feature.feature secure-stl : on off : propagated composite optional ; feature.compose <secure-stl>off : <define>_SECURE_SCL=0 <define>_CRT_SECURE_NO_DEPRECATE=1 <define>_SCL_SECURE_NO_DEPRECATE=1 <define>_CRT_NONSTDC_NO_DEPRECATE=1 ;
And then add
<secure-stl>off
to the requirements.
I am in favor of libraries being named differently, eg. with "_nsc" suffix.
Oh please yes. I always compile boost with secure_scl and a few others things disabled (or some of my programs take exponentially longer to run). Having name-mangled libraries for having those enabled or disabled would be perfect.
For note, here is the full build line I use: ..\bjam --build-type=complete --toolset=msvc-8.0 --without-mpi --prefix=R:/SDKs/boost/built_head --build-dir=R:/SDKs/boost/build_head define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log That _HAS_ITERATOR_DEBUGGING is also another really nasty one (_secure_scl may also disable it, but better safe then sorry, it bit me in the rear and cost me a couple of days when I first encountered the massive slowdowns it causes at times), causes the debug builds of some of my programs to be over 1500 times (yes, 1500 times, not 1500 percentage) slower then the debug builds with _HAS_ITERATOR_DEBUGGING=0 set in certain areas, that is just way too much of a speed hit to allow for any real debugging.
Thorsten Ottosen schrieb:
Hansi skrev:
Is there any interrest to get also compiled libraries for _SECURE_SCL enabled and _SECURE_SCL disabled?
Yes. I define
import feature ;
# # Composite feaure that ensures <define> can propagate # to all dependencies, not just sub-projects. #
feature.feature secure-stl : on off : propagated composite optional ; feature.compose <secure-stl>off : <define>_SECURE_SCL=0 <define>_CRT_SECURE_NO_DEPRECATE=1 <define>_SCL_SECURE_NO_DEPRECATE=1 <define>_CRT_NONSTDC_NO_DEPRECATE=1 ;
I wouldn't add _CRT_NONSTDC_NO_DEPRECATE to the feature because it isn't related to the *ms secure* functions but only deprecates posix named functions that have an iso c++ conformant named variant (according to the MSDN). Klaus Triendl
participants (6)
-
Emil Dotchevski -
Hansi -
Jean-Francois Bastien -
klaus triendl -
OvermindDL1 -
Thorsten Ottosen