What plans to handle _SCEURE_SCL in the boost build system?
Hi, There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it. At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam. Is someone working on this? Thanks. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________
Hello James, JT> At a minimum the build system should be changed to enable those JT> users wanting _SECURE_SCL=0 to do so easily - ideally by providing JT> an argument to bjam. It is already can be achieved easily by providing an argument to bjam. bjam define=_SECURE_SCL=0 That's all. -- -- Vyacheslav E. Andrejev -- System Architect, Optech International, Inc.
On Thu, Apr 24, 2008 at 12:53 AM, James Talbut <James.Talbut@omg3d.com> wrote:
Hi,
There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it.
At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam.
Is someone working on this?
I'd love to see someone pick up the ball on this one. For what it's worth, I've patched my local msvc.jam to add the feature: feature.feature stl-security-theater : off on : propagated link-incompatible ; flags msvc.compile C++FLAGS <stl-security-theater>off : /D_SECURE_SCL=0 ; flags msvc.compile C++FLAGS <stl-security-theater>on : /D_SCL_SECURE=1 ; As a result of our analysis of the benefits vs. performance of the "feature", I've set _SECURE_SCL=0 off by default. I asked on the build list how to augment library name mangling to make it safer, but haven't received a reply yet, so I may have to study a bit to make it better. But I will probably just ship it as above with Adobe Source Libraries 1.037. -Mat
Mat Marcus wrote:
On Thu, Apr 24, 2008 at 12:53 AM, James Talbut <James.Talbut@omg3d.com> wrote:
Hi,
There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it.
At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam.
Is someone working on this?
I'd love to see someone pick up the ball on this one. For what it's worth, I've patched my local msvc.jam to add the feature:
feature.feature stl-security-theater : off on : propagated link-incompatible ;
flags msvc.compile C++FLAGS <stl-security-theater>off : /D_SECURE_SCL=0 ; flags msvc.compile C++FLAGS <stl-security-theater>on : /D_SCL_SECURE=1 ;
As a result of our analysis of the benefits vs. performance of the "feature", I've set _SECURE_SCL=0 off by default. I asked on the build list how to augment library name mangling to make it safer, but haven't received a reply yet, so I may have to study a bit to make it better. But I will probably just ship it as above with Adobe Source Libraries 1.037.
Hi Mat, Is it the secure SCL that is causing your problem, or more specifically the iterator debugging feature? I agree that MSVC's iterator debugging can cause huge performance problems, and I've had to disable it in the accumulator's tests to get them to complete in any reasonable amount of time. Here's the bjam magic I use for that: # bring in rules for testing import testing ; import feature ; feature.feature iterator_debugging : on off : composite propagated optional ; feature.compose <iterator_debugging>off : <define>_HAS_ITERATOR_DEBUGGING=0 ; project : requirements <library>/boost/test//boost_unit_test_framework <link>static <include>../../.. <toolset>msvc:<define>_SCL_SECURE_NO_DEPRECATE # MSVC's iterator debugging causes some tests to run forever. <toolset>msvc:<iterator_debugging>off <toolset>intel-win:<iterator_debugging>off ; Now, since <iterator-debugging> is a feature, boost.build ensures that the test framework (against which I link) is also built with this feature -- very important because this setting breaks binary compatibility. The resulting binaries are placed in paths whose named encode the value of this feature, so I can't inadvertently link to an incompatible lib. Does that help any? Maybe someone could add this feature to BBv2 proper. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Thu, Apr 24, 2008 at 2:03 PM, Eric Niebler <eric@boost-consulting.com> wrote:
Mat Marcus wrote:
On Thu, Apr 24, 2008 at 12:53 AM, James Talbut <James.Talbut@omg3d.com> wrote:
Hi,
There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it.
At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam.
Is someone working on this?
I'd love to see someone pick up the ball on this one. For what it's worth, I've patched my local msvc.jam to add the feature:
feature.feature stl-security-theater : off on : propagated link-incompatible ;
flags msvc.compile C++FLAGS <stl-security-theater>off : /D_SECURE_SCL=0 ; flags msvc.compile C++FLAGS <stl-security-theater>on : /D_SCL_SECURE=1 ;
As a result of our analysis of the benefits vs. performance of the "feature", I've set _SECURE_SCL=0 off by default. I asked on the build list how to augment library name mangling to make it safer, but haven't received a reply yet, so I may have to study a bit to make it better. But I will probably just ship it as above with Adobe Source Libraries 1.037.
Hi Mat,
Is it the secure SCL that is causing your problem, or more specifically the iterator debugging feature? I agree that MSVC's iterator debugging can cause huge performance problems, and I've had to disable it in the accumulator's tests to get them to complete in any reasonable amount of time.
[snip] I maintain that _SECURE_SCL must be 0 by default for (at least) *release* builds. This is different from the MS default. I posted my rationale and some benchmark results at http://easyurl.net/high_cost , in case you are interested. As far as I know iterator debugging is not turned on by default for release builds, so it is not my primary concern here. Please let me know if I have missed something, though. Thanks for the suggestion, Mat
James Talbut wrote:
Hi,
There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it.
At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam.
Is someone working on this?
How about putting: <toolset-msvc:version>8.0:<define>_CRT_SECURE_NO_DEPRECATE <toolset-msvc:version>8.0:<define>_SCL_SECURE_NO_DEPRECATE Into the requirements section of your project? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
On Fri, Apr 25, 2008 at 8:40 AM, Roland Schwarz <roland.schwarz@chello.at> wrote:
James Talbut wrote:
Hi,
There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it.
At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam.
Is someone working on this?
How about putting: <toolset-msvc:version>8.0:<define>_CRT_SECURE_NO_DEPRECATE <toolset-msvc:version>8.0:<define>_SCL_SECURE_NO_DEPRECATE
Into the requirements section of your project?
Those are about whether the compiler should emit warnings when using std STL constructs that MS deems unsafe. They have nothing to do with the performance penalty alleviated by setting _SECURE_SCL=0. The problem is that we, I believe unintentionally, ship a build system that penalizes release builds by default.
participants (5)
-
Eric Niebler -
James Talbut -
Mat Marcus -
Roland Schwarz -
Vyacheslav E. Andrejev