[boost.build] should we not define _SECURE_SCL=0 by default for all msvc toolsets
Dear all, Is there are reason why we do not compile with this flag set by default? Are there any users of Boost out there which actually wants the securuty mode turned on? If not, then I suggest that we change the build settings. Thanks in advance -Thorsten
Thorsten, On Thu, Dec 4, 2008 at 3:05 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
Dear all,
Is there are reason why we do not compile with this flag set by default? Are there any users of Boost out there which actually wants the securuty mode turned on?
I personally prefer to have _SECURE_SCL=0 in Release builds too. For users that also have to build against other libraries that are provided as precompiled binaries that use the MSVC defaults this would break things. The _SECURE_SCL setting changes the ABI.
If not, then I suggest that we change the build settings.
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
Thanks in advance
-Thorsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
HTH, Neil Groves
Neil Groves skrev:
Thorsten,
On Thu, Dec 4, 2008 at 3:05 PM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
Dear all,
Is there are reason why we do not compile with this flag set by default? Are there any users of Boost out there which actually wants the securuty mode turned on?
I personally prefer to have _SECURE_SCL=0 in Release builds too. For users that also have to build against other libraries that are provided as precompiled binaries that use the MSVC defaults this would break things. The _SECURE_SCL setting changes the ABI.
If not, then I suggest that we change the build settings.
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0. -Thorsten
Thorsten Ottosen wrote:
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
Agree 100%, our default should equal the compiler default, otherwise it'll catch too many folks out.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default. One thing I hope we can all agree on: this should be a toolset feature, and it should change the library-name-mangling so that auto_link.hpp can select the correct binary (it doesn't at present, but just let me know what the correct name-mangling is and I'll fix that). John.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default.
One thing I hope we can all agree on: this should be a toolset feature, and it should change the library-name-mangling so that auto_link.hpp can select the correct binary (it doesn't at present, but just let me know what the correct name-mangling is and I'll fix that).
There have been a few discussions in the past on this, see this little research and proposal I did a few weeks ago: http://www.nabble.com/MSVC-_SECURE_SCL-causes-ABI-change%2C-ODR-violatio n---mangle-library-names--td19919013.html#a19919013 JF
John Maddock skrev:
Thorsten Ottosen wrote:
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
Agree 100%, our default should equal the compiler default, otherwise it'll catch too many folks out.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default.
Dave, since its your company that prevides the binary, can you comment on this? -Thorsten
on Fri Dec 05 2008, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
John Maddock skrev:
Thorsten Ottosen wrote:
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
Agree 100%, our default should equal the compiler default, otherwise it'll catch too many folks out.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default.
Dave, since its your company that prevides the binary, can you comment on this?
Our binaries are built the standard way that bjam makes them. We don't do anything special to add _SECURE_SCL=0. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I don't have any experience with bjam and so on. But I think it would be a good idea to provide libraries with and without _SECURE_SCL (and different library name). If I can do some work for that.. David Abrahams schrieb:
on Fri Dec 05 2008, Thorsten Ottosen <thorsten.ottosen-AT-dezide.com> wrote:
John Maddock skrev:
Thorsten Ottosen wrote:
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness! Agree 100%, our default should equal the compiler default, otherwise it'll catch too many folks out.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0. Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default. Dave, since its your company that prevides the binary, can you comment on this?
Our binaries are built the standard way that bjam makes them. We don't do anything special to add _SECURE_SCL=0.
On Fri, 19 Dec 2008 11:07:53 +0100, Hansi <hansipet@web.de> wrote:
I don't have any experience with bjam and so on. But I think it would be a good idea to provide libraries with and without _SECURE_SCL (and different library name). If I can do some work for that..
I think it's just a question of writing the right config for bjam. -- EA
I will check it..but I have no experience with bjam...I think it is really important because it is a ABI change!!! Edouard A. schrieb:
On Fri, 19 Dec 2008 11:07:53 +0100, Hansi <hansipet@web.de> wrote:
I don't have any experience with bjam and so on. But I think it would be a good idea to provide libraries with and without _SECURE_SCL (and different library name). If I can do some work for that..
I think it's just a question of writing the right config for bjam.
It is important that we get another name for the library! similar to the debug libraries or mulithreading libraries... Edouard A. schrieb:
I will check it..but I have no experience with bjam...I think it is really important because it is a ABI change!!!
I'm not sure but I think you can do something like bjam cxxflags=-D_SECURE_SCL=0
I have to agree with this. Another boost configuration that disables all that Microsoft crap that slows down code for no good reason would be wonderful. I personally build Boost myself with this command (in a batch file): ..\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 I compile everything I ever get that even touches the STL with the above defines, else nice crashes abound. But for an example, a parser I made with Boost.Spirit took 5 minutes without the above defines, took 5 second with them (times are pretty accurate, it was a massive difference), that is how utterly crappy the STL implementation is in VS2k5 and higher without those.
On Fri, Dec 19, 2008 at 9:36 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
I have to agree with this. Another boost configuration that disables all that Microsoft crap that slows down code for no good reason would be wonderful. I personally build Boost myself with this command (in a batch file):
..\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
I'm not against a separate configuration that disables these things but I'm happy with the default release the way it is; I find the STL checks in the Microsoft implementation quite helpful. I've found that usually I don't have any reasons to disable them. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
The checks are however a huge performance hit that people tend to be caught by surprise with. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Emil Dotchevski" <emildotchevski@gmail.com> Date: Fri, 19 Dec 2008 10:58:53 To: <boost@lists.boost.org> Subject: Re: [boost] [boost.build] should we not define _SECURE_SCL=0 by default for all msvc toolsets On Fri, Dec 19, 2008 at 9:36 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
I have to agree with this. Another boost configuration that disables all that Microsoft crap that slows down code for no good reason would be wonderful. I personally build Boost myself with this command (in a batch file):
..\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
I'm not against a separate configuration that disables these things but I'm happy with the default release the way it is; I find the STL checks in the Microsoft implementation quite helpful. I've found that usually I don't have any reasons to disable them. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Dec 19, 2008 at 10:34 PM, <raindog@macrohmasheen.com> wrote:
The checks are however a huge performance hit that people tend to be caught by surprise with.
Not my experience. The checks do affect performance, but rarely enough to get on my radar. I do like having them on by default. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
on Fri Dec 19 2008, "Emil Dotchevski" <emildotchevski-AT-gmail.com> wrote:
On Fri, Dec 19, 2008 at 10:34 PM, <raindog@macrohmasheen.com> wrote:
The checks are however a huge performance hit that people tend to be caught by surprise with.
Not my experience. The checks do affect performance, but rarely enough to get on my radar. I do like having them on by default.
They are without a doubt extremely useful for catching mistakes, but having them on in released code is absolutely antithetical to the design principles of the STL and of generic programming in general, which strives to raise components to the highest level of abstraction **without loss of efficiency**. If I understand correctly, it also causes the library not to meed the standard's performance requirements. Anyway, I agree that we must make it easy, if not the default, to install libraries compatible with the MS default ABI. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I'm not against a separate configuration that disables these things but I'm happy with the default release the way it is; I find the STL checks in the Microsoft implementation quite helpful. I've found that usually I don't have any reasons to disable them.
I think disabling the Microsoft checks only make sense for the release version, in debug they are indeed life savers. -- EA
You are right there is no reason to disable them totally. But it would be great to have the libraries with and without SECURE_SCL in parallel so everyone could decide to switch between the 2 modes Regards Hansjörg Emil Dotchevski schrieb:
On Fri, Dec 19, 2008 at 9:36 AM, OvermindDL1 <overminddl1@gmail.com> wrote:
I have to agree with this. Another boost configuration that disables all that Microsoft crap that slows down code for no good reason would be wonderful. I personally build Boost myself with this command (in a batch file):
..\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
I'm not against a separate configuration that disables these things but I'm happy with the default release the way it is; I find the STL checks in the Microsoft implementation quite helpful. I've found that usually I don't have any reasons to disable them.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
OvermindDL1 schrieb:
I compile everything I ever get that even touches the STL with the above defines, else nice crashes abound.
But for an example, a parser I made with Boost.Spirit took 5 minutes without the above defines, took 5 second with them (times are pretty accurate, it was a massive difference), that is how utterly crappy the STL implementation is in VS2k5 and higher without those.
You should try and send that exactly as is to the microsoft guys, as they are playing with the idea of disabling the _SECURE_SCL stuff in release builds by default. The more reasons they get for doing so, the better. Cheers, Anteru
On Sat, Dec 20, 2008 at 1:02 PM, Anteru <newsgroups@catchall.shelter13.net> wrote:
OvermindDL1 schrieb:
I compile everything I ever get that even touches the STL with the above defines, else nice crashes abound.
But for an example, a parser I made with Boost.Spirit took 5 minutes without the above defines, took 5 second with them (times are pretty accurate, it was a massive difference), that is how utterly crappy the STL implementation is in VS2k5 and higher without those.
You should try and send that exactly as is to the microsoft guys, as they are playing with the idea of disabling the _SECURE_SCL stuff in release builds by default.
The more reasons they get for doing so, the better.
Do you have a link to send me to for that? I buy VS by itself, I do not have an MSDN subscription (I do not even make that much spare money a year), as such I do not often stay with the 'in' Microsoft community, end up figuring most out by myself. I actually compile more for *nix, but all by coding takes place in Visual C++ and Visual Assist until there is a 'nix IDE that is mostly-comparable. Just this issue was odd in that GCC *vastly* outperformed VS, when usually VS is usually a 'little' bit faster then GCC in compiled code, had to look in to it.
..\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
But yes, this bjam line is rather essential for a few of my projects. I would love another build option that had this as an extra set as right now I have two boost directories, one for normal builds, one for the above (although I generally just use the above, as I have not made addon libraries for other apps that use the STL externally recently...).
OvermindDL1 schrieb:
Do you have a link to send me to for that? I buy VS by itself, I do not have an MSDN subscription (I do not even make that much spare money a year), as such I do not often stay with the 'in' Microsoft community, end up figuring most out by myself. I actually compile more for *nix, but all by coding takes place in Visual C++ and Visual Assist until there is a 'nix IDE that is mostly-comparable. Just this issue was odd in that GCC *vastly* outperformed VS, when usually VS is usually a 'little' bit faster then GCC in compiled code, had to look in to it.
I guess stl@microsoft.com should do the job. That should be their STL developer (Stephan T. Lavavej). Cheers, Anteru
On Sun, Dec 21, 2008 at 2:06 PM, Anteru <newsgroups@catchall.shelter13.net> wrote:
OvermindDL1 schrieb:
Do you have a link to send me to for that? I buy VS by itself, I do not have an MSDN subscription (I do not even make that much spare money a year), as such I do not often stay with the 'in' Microsoft community, end up figuring most out by myself. I actually compile more for *nix, but all by coding takes place in Visual C++ and Visual Assist until there is a 'nix IDE that is mostly-comparable. Just this issue was odd in that GCC *vastly* outperformed VS, when usually VS is usually a 'little' bit faster then GCC in compiled code, had to look in to it.
I guess stl@microsoft.com should do the job. That should be their STL developer (Stephan T. Lavavej).
Ah, thanks. I have a wonderful example to send that shows how without the above commands completely destroys many optimization opportunities... So, to poke everyone again. Is it planned to add the above line as another build configuration?
Anteru wrote:
OvermindDL1 schrieb:
Do you have a link to send me to for that? I buy VS by itself, I do not have an MSDN subscription (I do not even make that much spare money a year), as such I do not often stay with the 'in' Microsoft community, end up figuring most out by myself. I actually compile more for *nix, but all by coding takes place in Visual C++ and Visual Assist until there is a 'nix IDE that is mostly-comparable. Just this issue was odd in that GCC *vastly* outperformed VS, when usually VS is usually a 'little' bit faster then GCC in compiled code, had to look in to it.
I guess stl@microsoft.com should do the job. That should be their STL developer (Stephan T. Lavavej).
Microsoft's STL developer's initials are S.T.L.? That's amazing. -- Michael Marcin
John Maddock skrev:
Thorsten Ottosen wrote:
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
Agree 100%, our default should equal the compiler default, otherwise it'll catch too many folks out.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default.
One thing I hope we can all agree on: this should be a toolset feature, and it should change the library-name-mangling so that auto_link.hpp can select the correct binary (it doesn't at present, but just let me know what the correct name-mangling is and I'll fix that).
what about adding "-nsl" (no secure library) in the name? -Thorsten
Thorsten Ottosen wrote:
John Maddock skrev:
Thorsten Ottosen wrote:
I think it would be ok to allow both options, but probably the default should equal the Microsoft default with an easy way to opt-out of the madness!
Agree 100%, our default should equal the compiler default, otherwise it'll catch too many folks out.
But AFAIK, even the prebuilt binaries that you get from Boost Consulting are built with _SECURE_SCL=0.
Really ??? I hadn't realised that, that's not good IMO, given that the define changes the ABI away from the compilers default.
One thing I hope we can all agree on: this should be a toolset feature, and it should change the library-name-mangling so that auto_link.hpp can select the correct binary (it doesn't at present, but just let me know what the correct name-mangling is and I'll fix that).
what about adding "-nsl" (no secure library) in the name?
It would be nice to establish a clear policy that allows us, given a compiler option -do-random-nonsense to determine: - whether there should be Boost.Build feature for that option - what values of that options should be built by default - should the value of that option be included in the library name There's infinitely many options, and infinitely many of them change ABI, so I don't know offhand how to decide on these questions. Anybody can suggest anything? - Volodya
Vladimir Prus wrote:
It would be nice to establish a clear policy that allows us, given a compiler option -do-random-nonsense to determine:
- whether there should be Boost.Build feature for that option
How about: "new features are randomly added based upon demand".
- what values of that options should be built by default
IMO always the same as the compiler uses by default. Of course we might run into issues if IDE's and command line compilers do different things by default, but we'll cross that bridge when we find it.
- should the value of that option be included in the library name
Yes, if it's commonly used and changes/breaks the compilers ABI. But of course given than N options give us 2^N library variants, we'll have to be careful how many of these options we add/support. John.
John Maddock wrote:
Vladimir Prus wrote:
It would be nice to establish a clear policy that allows us, given a compiler option -do-random-nonsense to determine:
- whether there should be Boost.Build feature for that option
How about: "new features are randomly added based upon demand".
This is probably ok.
- what values of that options should be built by default
IMO always the same as the compiler uses by default.
Well, but -- should we only build with the default value in the compiler? Or with all possible values?
- should the value of that option be included in the library name
Yes, if it's commonly used and changes/breaks the compilers ABI.
So, we need a definition of "commonly"? There should be a line beyond which the user is supposed to explicitly build extra variant, and deal with the naming himself.
But of course given than N options give us 2^N library variants, we'll have to be careful how many of these options we add/support.
Yes, this is the primary concern. - Volodya
participants (13)
-
Anteru -
David Abrahams -
Edouard A. -
Emil Dotchevski -
Hansi -
Jean-Francois Bastien -
John Maddock -
Michael Marcin -
Neil Groves -
OvermindDL1 -
raindog＠macrohmasheen.com -
Thorsten Ottosen -
Vladimir Prus