Following up, I've been investigating the problem with STLPort builds of the serialization system. I believe that the explanation why your tests fail and mine pass are due to the fact that your tests build/test using the stlport dll and I was using the static library version. Now I'm building with the DLL libraries and I'm getting similar results to those you are. I believe the problem is that STLPort file _locale.h contains code like the following: class _STLP_CLASS_DECLSPEC locale { ... template <class _Facet> locale(const locale& __loc, _Facet* __f) : _M_impl(0) { ... } }; Where _STLP_CLASS_DECLSPEC is defined as __declspec( dllimport ) when the header is used for purpose other than building the stlport dll. The templated constructor is invoked by the serialization library. Unfortunately, the functions for the locale class definition is already compiled and already in the dll. At link time the template - even inline - are not found. I would characterize this a conflict between the class export dll implementation and templated constructors - which this implemention requires. I'm not yet sure how to handle this now - anyone who wants can post a suggestion. Meanwhile, I'll keep thinking about it. Robert Ramey
-----Original Message----- From: Aleksey Gurtovoy [mailto:agurtovoy@meta-comm.com] Sent: Wednesday, September 29, 2004 9:42 AM To: Cc: Robert Ramey; Boost Regression Subject: Re: [boost] Test failure with STLPort
[Robert, sorry for the late reply]
I've noticed that you are testing the serialization library with the toolset msvc-stlport.
I've tested that here and got most of to pass - at least as well as standard msvc.
I had to make some changes though and I believe that you will have to make similar ones if you want the test to pass.
I had to invoke the following before running the tests.
export STLPORT_PATH="c:/" export STLPORT_VERSION=4.5.3 export STLPORT_INCLUDE_DIRECTORY="c:/program files/Microsoft Visual Studio/vc98/include/stlport"
my stlport install process created a special set of stlport header files in the msvc include directory. This is and altered version of the original ones. The original ones compiler ok but they have some switches set so
some inline code is not included and this makes the test builds fail at
Robert Ramey writes: that link
time.
I'm afraid this claim is incorrect. I just performed the install process you are talking about above and the headers that end up in the "C:\Program Files\Microsoft Visual Studio\VC98\Include\stlport\" directory are *exactly* the same as the ones from a freshly unpacked archive. File to file, byte to byte. You can use any kind of directory comparison tool to verify it yourself.
So, whatever causes the differences in results you are seeing locally and the results reported in the regression reports, it's not a misconfigured installation.
Hmm, looking at the serialization library errors with our msvc-stlport toolset (MSVC 6.5/STLPort 4.5.3) -- the following, for instance (from http://tinyurl.com/6eavf), -- there is no way this could have linked in the same configuration (that is, dynamically linking to STLPort):
Creating library C:\Users\Administrator\boost\main\results\bin\boost\libs\serialization\tes t\test_array_binary_archive.test\msvc-stlport\debug\thread ing-multi\test_array_binary_archive.lib and object C:\Users\Administrator\boost\main\results\bin\boost\libs\serialization\tes t\test_array_binary_archive.test\msvc-stlport\debug\thread ing-multi\test_array_binary_archive.exp libboost_serialization.lib(binary_oarchive.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall _STL::locale::locale(class locale::locale const &, ^^^^^^^^^^^^^^^^^^^^^ class boost::archive::codecvt_null<char> *)" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The missing symbol above is an specialization of a member function template of a dllimport-ed class (_STL::locale) residing in the STLPort DLL, which (member template) is parametrized by a user-defined type. This is *known* not to work with MSVC 6.x; the DLL doesn't contain the requested specialization (naturally), and the compiler fails to instantiate one on demand in the current translation unit. See, for instance, http://tinyurl.com/4a4xq.
Are you sure you are building in this exact configuration, using bjam + standard 'msvc-stlport' toolset from the CVS + unmodified STLPort 4.5.3 installation? Could you please double-check that?
If could upload your bjam log of such successful build to our FTP (ftp://fx.meta-comm.com/boost-regression), it would be also appreciated.
We really need to sort this out, so if anybody has anything to add to the above, please do!
-- Aleksey Gurtovoy MetaCommunications Engineering