|
Hallo Armin. Thanks a lot for your response. 1. In Visual-C++ the _SECURE_SCL-flag enables some special security checks within the STL-Container-templates. This means among others that the base-classes for all iterators get an additional member, a pointer to the referenced container. This pointer in turn is used to make additional runtime-checks, if an iterator is actually pointing into the container it is used with. To my opinion this is quite useful in debug-mode, but for release-versions, these checks can easily slow down the performance of programs by 10-20% and more, depending on the algorithms used. Since _SECURE_SCL=0 removes the additional pointer-member from the iterators, the binary-compatiblility with libraries in 'secure-mode' is broken. Anyway. MS has decided to make _SECURE_SCL=1 the default, for both release- and debug-mode. Which leads me to... 2. I totally agree with pre-built libraries compiled with the default-settings of a compiler. I did not really expect an additional customized build for my purposes. That's why I asked for a known workaround. It could be that sigc++ is the only source of problems, since it exchanges iterators in its interface (signal::connect()). If so, I would mail to their list, but I do not really know if there is other items somewhere in the libraries that are also affected and I cannot double-check the complete code... 3. I found the instructions on http://live.gnome.org/gtkmm/MSWindows/BuildingGtkmm . But I would rather like to rebuild exactly the libs and dlls, that come with the installer-packages. Where can I find out, which packages of libsigc++, glibmm, cairomm, pangomm and gtkmm were exactly used for the installers? The idea is, if I rebuild exactly the same versions, I could just exchange the release-libs and -dlls of the standard gtkmm-installation and are finished. Maybe there is even a complete VisualC++-Workspace (sln) for all C++-libraries at once, that could be released along with the installers? Any aid in building a 'patch' for the installers would be welcome. regards Thomas Armin Burgmeier wrote: 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. 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? 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. However, considering the rules posted on [1], I don't see an easy workaround for your problem without rebuilding the involved C++ libraries. Armin [1] http://blogs.msdn.com/vcblog/archive/2007/08/10/the-future-of-the-c-language.aspx#4617984 |