incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farid Zaripov" <Farid_Zari...@epam.com>
Subject RE: Boost + Stdcxx (results)
Date Thu, 05 Apr 2007 07:42:21 GMT
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Wednesday, April 04, 2007 8:40 PM
> To: stdcxx-dev@incubator.apache.org
> Cc: stdcxx-user@incubator.apache.org
> Subject: Re: Boost + Stdcxx (results)
> 
> Farid Zaripov wrote:
> >   The results of the regression tests are here:
> > http://people.apache.org/~faridz/status/cs-win32-full.html
> 
> Great, thanks for posting these! Do you happen to have the 
> same set of results with the native C++ Standard Library that 
> we could use as a baseline for comparison?

  I will do this. But at the moment you can see the tests results here:
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/sum
mary.html

> Skimming quickly through the results I see a lot of 
> compilation errors due to the same incorrect assumptions 
> about which headers symbols are referenced in as in the rest 
> of Boost. We should open bugs for those as well (any 
> preference for how to handle those?)

  I'd like to submit the tests results to the boost developers and they
can fix the all bugs, but I think that posting the issues to the
bugtracking
database will be more reliable.

> I also noticed quite a number of exceptions due to no RTTI data.
> I wonder if we might need a compiler option to enable RTTI 
> when building the tests or perhaps even the library.

  The tests builds with the RTTI turned on. We need to build the
stdcxx library with RTTI.

> Then there are a whole bunch of linker errors LNK1104. Any 
> idea what those are about? Did those libraries fail to build? 
> Is it because the tests were built with /Zc:wchar_t and our 
> library wasn't?

  I don't think so. I suppose that problem is somewhere in .jam files
because of library which is not found is the not stdcxx library (without
'x' suffix).
For example here searched libboost_serialization-vc80-mt-gd-1_33_1.lib,
but should be used libboost_serialization-vc80-mt-gdx-1_33_1.lib:
-------------------
serialization - test_vector_binary_archive - vc-8_0-stdcxx
Compiler output:

test_vector.cpp
Linking to lib file: libboost_serialization-vc80-mt-gd-1_33_1.lib
Linking to lib file: libboost_serialization-vc80-mt-gd-1_33_1.lib

Linker output:

LINK : fatal error LNK1104: cannot open file
'libboost_serialization-vc80-mt-gd-1_33_1.lib'

    CALL "D:\Program Files\Microsoft Visual Studio
8\Common7\Tools\..\..\VC\bin\vcvars32.BAT" >nul 
    "D:\Program Files\Microsoft Visual Studio
8\Common7\Tools\..\..\VC\bin\link"  /nologo  /DEBUG /subsystem:console
/out:"..\bin\boost\libs\serialization\test\test_vector_binary_archive.te
st\vc-8_0-stdcxx\debug\threading-multi\test_vector_binary_archive.exe"
/LIBPATH:"..\bin\boost\libs\test\build\libboost_test_exec_monitor.lib\vc
-8_0-stdcxx\debug\threading-multi"
/LIBPATH:"..\bin\boost\libs\serialization\build\libboost_serialization.l
ib\vc-8_0-stdcxx\debug\threading-multi"
/LIBPATH:"D:\_Projects\stdcxx_working\build\msvc-8.0\15d\lib"
"stdlib15d.lib"
@"..\bin\boost\libs\serialization\test\test_vector_binary_archive.test\v
c-8_0-stdcxx\debug\threading-multi\test_vector_binary_archive.CMD" 
-------------------     


> Also, we might want to #define _CRT_SECURE_NO_DEPRECATE on 
> the command line to reduce the noise from all those darn 
> useless deprecation warnings.

  Yes, it makes sense.

Farid.

Mime
View raw message