Re: Using gtkmm with Visual C++ and _SECURE_SCL=0

[Balazs Scheidler <bazsi balabit hu>]

On Sat, 2008-10-18 at 16:30 +0200, Maik Beckmann wrote:
> 2008/10/18 Armin Burgmeier <armin arbur net>:
> > On Fri, 2008-10-17 at 16:05 +0200, Thomas Frank wrote:
> >> I searched for _SECURE_SCL in the archives but didn't get any results.
> >> Has this ever been a topic?
> >
> > I didn't even know this option existed. Of course, we could enable this
> > for the gtkmm runtime binaries, but then people need to set the same
> > flag in their applications, which is just one step more that could go
> > wrong. This is why I would rather avoid it.
> 
> _SECURE_SCL=1 is similar to libstdc++ Debug Mode
>  - http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
> <quote>
> To use the libstdc++ debug mode, compile your application with the
> compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes
> and behavior of standard class templates such as std::vector, and
> therefore you can only link code compiled with debug mode and code
> compiled without debug mode if no instantiation of a container is
> passed between the two translation units.
> </quote>
> which means binary incompatibility.
> 
> > We could also supply release binaries for both _SECURE_SCL=0 and
> > _SECURE_SCL=1 (so we would have 6 different VC++ DLLs for each C++
> > module). Again, I'm not quite happy with this considering the
> > duplication it involves.
> >
> > How many applications do (need to) use the _SECURE_SCL=0 option? Is it
> > kind of standard that it is used for release builds?
> 
> The VS default release build doesn't define _SECURE_SCL=0 by default,
> AFAIK.  If you just compile the header files define _SECURE_SCL=1 by
> default.
> 
> > If not, then I'm
> > sorry, but I don't think it's reasonable to support all the different
> > MSVC++ compiler settings that produce incompatible binaries. Just
> > because there are too much of them.
> 
> My impressions is, that performance suffers when using std containers
> and algorithm with _SECURE_SCL=1.  This might be a problem when i.e.
> doing heavy duty text processing using the stl.
> 
> I for example was bitten by _SECURE_SCL=1 being the default :-).
> Coding a ND-LookupTable, mingw-gcc-4.2.3 outperformed msvc-8.0 by a
> factor of 2.5. A few month later I've read posting about this topic at
> the boost-ML.  Rebuilding everything with _SECURE_SCL=0 made msvc
> outperform gcc by a factor of 1.3.
> 
> > However, considering the rules posted on [1], I don't see an easy
> > workaround for your problem without rebuilding the involved C++
> > libraries.
> 
> It would be best to have generic build scripts for msvc.  Do the
> autotools scripts work with CC=cl CXX=cl?
> 
> A workaround is using LoadLibrary to open _SECURE_SCL=0 compiled DSOs
> containing performance critical code.

We're building glibmm using a wrapper script called cccl, which emulates
UNIX like cc options with the Microsoft compiler.

As far as I know it was an abandoned project, but one of my collegues
updated it somewhat to work better. As far as I know it still needs some
magic to actually produce working binaries, but that's the best option I
had so far to compile the gtkmm stack with MSVC++.

What does the binary installer use to compile gtkmm on Windows? Or you
are using mingw?

So if anyone is interested I'd be willing to publish our cccl fork,
maybe it could be cleaned up a bit. It would make it way easier to
compile Windows binaries by ourselves and in that case
binary-incompatible MSVC options would not bite that much.

-- 
Bazsi