Project

General

Profile

_SCL_SECURE=0 for release build on Windows

Added by Anonymous over 13 years ago

Hi All,

Currently the Wt build does not explicitly set the value of the _SCL_SECURE preprocessor directive. I think it would be nice to have a CMake option to force _SCL_SECURE to a particular value, especially for the release build. FYI, the default on VS2008 is "1", while it has changed to "0" with VS2010.

VS2010 will give a linker warning if there is a mismatch between the "Iterator Debug Level" of translation units being linked, but VS2008 does not, so it would be up to the developer to ensure that Wt and its third party dependencies (eg, boost) are compatible when using VS2008.

Cheers,

Dan


Replies (3)

RE: _SCL_SECURE=0 for release build on Windows - Added by Wim Dumon over 13 years ago

Hey Paull,

Note that you can do this already. In cmake, check the 'Advanced' checkbox. Then look for CMAKE_CXX_FLAGS and CMAKE_C_FLAGS. Add whatever compiler flag you want to use to the list. If you only want it for the release builds, add it to the _release and_relwithdebinfo fields

I'd rather not do unexpected tricks with this flag in our cmake files. People who want to change the default setting of this flag are usually aware of the interoperability problems. AFAIK Wt now works consistent with boost, unless I'm missing something?

Best regards,

Wim.

RE: _SCL_SECURE=0 for release build on Windows - Added by Anonymous over 13 years ago

Wim Dumon wrote:

I'd rather not do unexpected tricks with this flag

The problem I see is that Microsoft have played an unexpected trick with this flag by changing the default value. Anyone using a pre-compiled version of a library that uses STL as part of its API may be bitten.

I'd like to have "Release" and "Secure Release" build targets in my build system to allow my applications to be build with _SCL_SECURE set to "0" and "1" respectively. Since these builds are not ABI compatible, they need to be build separately (imaging linking object files built with different values of _SCL_SECURE!) and be clearly identifiable (somewhat like the "d" appended for debug builds). This can only be achieved through separate build targets. The more vendor support I have for this, the less complex my build system needs to be.

If I'm the only developer who wants this build configuration then I can configure my own build, but I would have thought that just as many developers would like secure and non-secure build variants as developers that want separate Release and MinSizeRel builds...

Regarding Boost, my recollection from the boost mailing lists is that it is generally agreed that _SCL_SECURE should be set to "0" for release builds, but bjam still defaults to "1".

Cheers,

Dan

RE: _SCL_SECURE=0 for release build on Windows - Added by Wim Dumon over 13 years ago

Daniel Paull wrote:

Wim Dumon wrote:

> I'd rather not do unexpected tricks with this flag

The problem I see is that Microsoft have played an unexpected trick with this flag by changing the default value. Anyone using a pre-compiled version of a library that uses STL as part of its API may be bitten.

>

From what I've read, and from personal experience (learned it the hard way), in order to avoid trouble, all libraries used in a project should always be compiled with the exact same version of the compiler. Unless you (or some of the projects you use) explicitly change the flag, you're ok. But please correct me if my understanding of the problem is wrong! Knowing how to produce a correct build on Windows sometimes feels like mastering a black art.

I'd like to have "Release" and "Secure Release" build targets in my build system to allow my applications to be build with _SCL_SECURE set to "0" and "1" respectively. Since these builds are not ABI compatible, they need to be build separately (imaging linking object files built with different values of _SCL_SECURE!) and be clearly identifiable (somewhat like the "d" appended for debug builds). This can only be achieved through separate build targets. The more vendor support I have for this, the less complex my build system needs to be.

>

CMake defines these build targets by default: Debug, Release, MinSizeRel, RelWithDebInfo

The cmake wiki says that if you use the 'Makefiles' generator, you can add more build types by use of the CMAKE_BUILD_TYPE() function. About Visual Studio, it says that CMAKE_CONFIGURATION_TYPES lists the available configuration types; it does not say that you can modify them. But look, it is apparently in the FAQ:

http://www.cmake.org/Wiki/CMake_FAQ#How_to_create_Visual_Studio_6_Projects_that_contain_only_a_single_build_type

From what I read above, I believe it's possible to modify your CMake installation so that you enable this feature for all your cmake based projects.

If I'm the only developer who wants this build configuration then I can configure my own build, but I would have thought that just as many developers would like secure and non-secure build variants as developers that want separate Release and MinSizeRel builds...

>

Sounds reasonable. Maybe it's better to take this up on the cmake developers mailing list? I'm afraid that it is difficult to include this in Wt in a generic way, so that it works properly with current and future versions of cmake. If there is such a way, I'll surely include a patch for this.

BR,

Wim.

    (1-3/3)