Hi, I'm having trouble properly compiling Boost with the Dinkumware STL implementation (working with Visual C++ 7.1). The problem is that bjam always calls CL with a /I that pulls in Microsoft's include files first, so that they take precedence over the Dinkumware ones. This behavior seems to be rooted far down in the file Jambase located in jam_src. I don't really feel like fooling with that. What can I do? -- Jean-Pierre
Jean-Pierre Gygax wrote:
Hi,
I'm having trouble properly compiling Boost with the Dinkumware STL implementation (working with Visual C++ 7.1).
The problem is that bjam always calls CL with a /I that pulls in Microsoft's include files first, so that they take precedence over the Dinkumware ones.
This behavior seems to be rooted far down in the file Jambase located in jam_src. I don't really feel like fooling with that.
Boost.Build (w/bjam) doesn't the Jambase as provided by Perforce/Jam. SO it would be pointless to change it anyway ;-)
What can I do?
The best solution is to create a new toolset that supports Dinkumware STL on top of MSVC. If you are really interested in this the best model for this is the existing STLPort toolset. Look at the *-stlport-tools.jam and stlport.jam files in ../tools/build/v1. [1] The next best thing is to copy the msvc-tools.jam file to a msvc-dinkum-tools.jam file. And edit accordingly. If you want more detailed discussion for this the Boost.Build list. See: http://boost.org/more/mailing_lists.htm#projects for details on access. [1] It would be *really nice* to the Boost community at large if DinkumSTL support was created, ala stlport.jam, not just hacked in ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
I give up. I cannot make it work.
The next best thing is to copy the msvc-tools.jam file to a msvc-dinkum-tools.jam file. And edit accordingly.
This is what I tried for the whole day now. My reward: always the same
errors, LNK4006 followed by LNK2005 ("symbol already defined" on
basic_string and some other std stuff, see sample below). I can override
them with the linker flag /FORCE:MULTIPLE but then my DLL bails out in
anti-heap corruption asserts.
I compared every single compiler setting between my project and the boost
compiler invokations. I fixed quite a few differences, only to obtain no
change whatsoever to the result.
-- Jean-Pierre
libboost_regex-vc71-mt-gd-1_31.lib(winstances.obj) : error LNK2005: "class
std::basic_string
I give up. I cannot make it work.
The next best thing is to copy the msvc-tools.jam file to a msvc-dinkum-tools.jam file. And edit accordingly.
This is what I tried for the whole day now. My reward: always the same errors, LNK4006 followed by LNK2005 ("symbol already defined" on basic_string and some other std stuff, see sample below). I can override them with the linker flag /FORCE:MULTIPLE but then my DLL bails out in anti-heap corruption asserts.
I compared every single compiler setting between my project and the boost compiler invokations. I fixed quite a few differences, only to obtain no change whatsoever to the result.
Since there doesn't seem to be anyone around here whose also using an updated Dinkumware library, I'd suggest that you either: 1) Use the regex makefile provided (if it's just regex that you want), and modify the makefile to inject the appropriate #include. 2) Just build in the IDE, there's nothing special going on here: just grab the sources in libs/whatever/src/*.cpp to build library "whatever". (Caveat: the python and thread libs are slightly more complex than this, but not by much). John.
Since there doesn't seem to be anyone around here whose also using an updated Dinkumware library, I'd suggest that you either:
1) Use the regex makefile provided (if it's just regex that you want), and modify the makefile to inject the appropriate #include. 2) Just build in the IDE, there's nothing special going on here: just grab the sources in libs/whatever/src/*.cpp to build library "whatever". (Caveat: the python and thread libs are slightly more complex than this, but not by much).
Thanks John, but I've now "worked around" the problem by moving back to the standard library implementation that ships with vc7.1. I'd have done this earlier, but I used to have an unsolved problem that I have now finally pinned down - incidentally, that problem was the infamous "can't read binary files with streambuf under Windows", which is solved with Dinkum. (I wonder if other STL implementations like STLport have the same problem?) The second of your suggestions sounds promising though, didn't think of that at all. Then again, is there any real difference between building in the IDE and linking libs that were obtained by carefully synch'ing the compiler flags? What I'd really like to know is what the heck is going on. Why am I even having multiply defined symbols? And where did that heap corruption come from? -- Jean-Pierre
Thanks John, but I've now "worked around" the problem by moving back to the standard library implementation that ships with vc7.1.
I'd have done this earlier, but I used to have an unsolved problem that I have now finally pinned down - incidentally, that problem was the infamous "can't read binary files with streambuf under Windows", which is solved with Dinkum. (I wonder if other STL implementations like STLport have the same problem?)
The second of your suggestions sounds promising though, didn't think of that at all. Then again, is there any real difference between building in the IDE and linking libs that were obtained by carefully synch'ing the compiler flags?
No, there's no difference between building in your IDE or building with the command line tools, you may want to define BOOST_ALL_NO_LIB throughout to suppress automatic selection of the library name, and manually add your library to your .exe's dependencies though.
What I'd really like to know is what the heck is going on. Why am I even having multiply defined symbols? And where did that heap corruption come from?
No idea, you'd need to carefully examine command lines and the like to find out, probably the lib is built against the default std lib, and your .exe is built against the dinkumware one? John.
