Hey,

I hope you are linking against the debug boost libraries. I have noticed such problems if you use boost release built libraries with debug build of your application.

Yes - i did. Our better "it did". Boost is linking automaticly because auf the _DEBUG Macro. During compilation with the Macro BOOST_LIB_DIAGNOSTIC set, i got the following: 1>Linking to lib file: boost_thread-vc90-mt-gd-1_44.lib 1>Linking to lib file: libboost_date_time-vc90-mt-gd-1_44.lib IMHO the gd indicates the debug version. Thanks so far Simon

...

1>Linking to lib file: boost_thread-vc90-mt-gd-1_44.lib 1>Linking to lib file: libboost_date_time-vc90-mt-gd-1_44.lib

Looks to me like you're mixing static and dynamic libraries there. That might be the problem.

Yes, indeed. But i thought this is okay, because for boost::date_time no dynamic library will be build by bjam - just the static once. I will take a look if i create it dynamic, but at the moment bjam is not creating the dynamic one and the auto_link is also just including the static lib. Greetings M.Sc. Simon Adler

On Windows, using Visual C++, I have experienced crashes of optimised (release) build of a program linking against program_options from binaries of Boost 1.44 downloaded from boostpro.com.

Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.

Instead, you could compile boost with -D_SECURE_SCL But of course, boost libs and your program should be compiled with the same option.

...

...

Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.

I remember having the same issue with program_options a while ago. But why does that happen? What does program_option do that makes it so fragile without _SECURE_SCL? Other libs seems to work just fine. Regards, Christian

On 29/10/10 00:28, John Dlugosz wrote:

The std iterators or containers are different. I forget which option does what to them, but I have two such things in my project too. If stl items are passed between files compiled with different options, then boom.

Indeed, it's likely related to the problems explained here: Allocating and freeing memory across module boundaries http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

On Fri, Oct 29, 2010 at 9:56 AM, John Dlugosz wrote:

...

Indeed, it's likely related to the problems explained here:

Allocating and freeing memory across module boundaries

http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx

I've dealt with that by setting up projects to use the DLL version of the run-time library.  Even before that was the default in Visual Studio, it has this big advantage.  It's like virtual inheritance in C++:  all DLLs that link to the DLL RTL will refer to the _same_ copy of the RTL.

With Visual Studio 2008 (maybe it started earlier, I'm not sure) there is a new wrinkle:  different DLLs compiled with the same version of the compiler can refer to different patch versions of the RTL.  So, either make sure all DLLs are compiled with the default options (link to original RTL version regardless of newer ones available) or compile all with _BIND_TO_CURRENT_VCLIBS_VERSION=1 which binds to the latest version available at compile-time, with the same latest one seen at compile-time for each module.

It's crazy really.  Win32 addressed this issue by having a process global heap.  If all the copies of the RTL used that, they would interoperate just fine.  But the start-up code goes out of its way to ignore it and create its own heap instead, so each copy of the RTL is its own memory pool.

The problems reported by the OP have, if I read and remember correctly, with conditional compilation in the standard library headers.  Specifically, if debug builds are compiled with _HAS_ITERATOR_DEBUGGING=0 then all DLLs must be built that way.  Since the conditional compilation this triggers is in the STL iterators, than it's only a problem if iterators are involved in the calls or member accesses etc. across the DLL boundaries.

Likewise _SECURE_SCL=0 will change the layout of the STL container classes.  string and wstring are compatible across, since special support is included to make that polymorphic at run-time and allow those instantiations to live inside the single DLL.  But other containers will change their size, messing up other structures that contain them, and calls using them will refer to wrong addresses.  So, if STL is involved, the DLLs must have this option set the same way.

Personally, I solved this with Boost by remaking the Visual Studio project files for the (few) Boost DLLs I needed, and not using Jam at all.  I specifically recommend using a "property sheet" in Visual Studio to record these build conventions, and refer to the same property sheet in all the projects of your application suite.

I just build boost like this: 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=_CRT_SECURE_NO_WARNINGS define=_SECURE_SCL=0 define=_SCL_SECURE_NO_DEPRECATE define=_HAS_ITERATOR_DEBUGGING=0 install>..\build-HEAD.log 2>&1 Along with the appropriate macros in my own projects, I have no issues, and in some cases some tremendous speed benefits (iterator debugging slowed some of my apps down from running in milliseconds to running in 12 seconds, screw that!).

Hello, yes - you have solved my Problem - boost works. I just want do describe what i had to do, so new Users to boost may not be furstrated by a thread that is just finished with "problem solved", but not how .-) First i think the _SECURE_SCL Problem was the main problem. I solved this calling ./bjam link=shared cxxflags=-D_SECURE_SCL However, i was a little wrong. The Module time_date was build as dll, but it was included as static during compilation. This was, because I had declared BOOST_DYN_LINK and not BOOST_ALL_DYN_LINK in my preprozessor definitions. Now i can compile and execute my programm successfully. M.Sc. Simon Adler ------------------------------------------------------------------------------ Fraunhofer Institut für Fabrikbetrieb und -automatisierung IFF Virtual Development and Training Centre VDTC Joseph-von-Fraunhofer-Strasse 1 39106 Magdeburg Germany wissenschaftlcher Mitarbeiter (VP) Telefon +49 391/40 90-776 Internet: www.iff.fraunhofer.de boost-users-bounces@lists.boost.org schrieb am 29.10.2010 10:42:28:

Von: John Maddock An: Datum: 29.10.2010 10:45 Betreff: Re: [Boost-users] std::string corrupt after including boost Gesendet von: boost-users-bounces@lists.boost.org

...

...

...

...

Once I have removed #define _SECURE_SCL 0 from my program, craches disappeared.

I remember having the same issue with program_options a while ago. But why does that happen? What does program_option do that makes it so fragile without _SECURE_SCL?

Other libs seems to work just fine.

I believe that code compiled with that option is binary incompatible with code compiled without it - so if you link with a library that depends on a std lib symbol that changes it's interface based on that define, then you'd better be sure to use the same settings as that library (or else recompile the lib).

HTH, John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users