stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [Fwd: svn commit: r584880 - in /incubator/stdcxx/trunk/etc/config/src: NO_OBJECT_MANGLING.cpp object_mangling_imp.cpp]
Date Mon, 15 Oct 2007 22:16:01 GMT
Just as a heads up, even though this is a rather short notice,
since this test works as expected even on Windows/MSVC I'll go
ahead and merge it to 4.2.0 in preparation for the STDCXX-509
fix. If anyone has a problem with this, speak up.

Martin

Martin Sebor wrote:
> Travis Vitek wrote:
>> No. I should probably double-check before opening my yapper. Here is the
>> the log from the windows configuration step. Both source files are
>> compiled and the final link line links both objects as you're expecting.
> 
> Great, thanks for the confirmation! I've configured the library
> with Visual Studio 8 and it looks like the test works as expected,
> i.e., it correctly detects that the compiler mangles the type of
> objects into their names. I.e., _RWSTD_NO_OBJECT_MANGLING is not
> #defined.
> 
> Btw., in case anyone's wondering why I need this, it's to fix
> STDCXX-509 in a binary compatible way. The original fix I had
> come up with was binary compatible everywhere except for MSVC
> (due to the compiler mangling algorithm). The new one that's
> in place now, isn't binary compatible at all. So I'm thinking
> I'll go back to the original fix for all platforms but MSVC
> (or more generally, for all platfrms where the new
> _RWSTD_NO_OBJECT_MANGLING macro is #defined), and either come
> up with a special case solution for MSVC (e.g., try to mangle
> the name myself), or leave the bug there until we can break
> binary compatibility. Suggestions are welcome!
> 
> Martin
> 
>>
>> Travis
>>
>> Compiling with command "cl /c /EHsc /GS /D_CRT_SECURE_NO_DEPRECATE /GR
>> /MDd /Zi /Gm /I"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests"
>> /D"_RWSHARED" /Fo"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\\"
>> /Fd"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\object_mangling_imp
>> .pdb" "C:\Build\stdcxx-trunk\etc\config\src\object_mangling_imp.cpp""
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> object_mangling_imp.cpp
>>
>> Compiling with command "cl /c /EHsc /GS /D_CRT_SECURE_NO_DEPRECATE /GR
>> /MDd /Zi /Gm /I"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests"
>> /D"_RWSHARED" /Fo"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\\"
>> /Fd"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\NO_OBJECT_MANGLING.
>> pdb" "C:\Build\stdcxx-trunk\etc\config\src\NO_OBJECT_MANGLING.cpp""
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> NO_OBJECT_MANGLING.cpp
>>
>> Linking with command "cl
>> "C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\NO_OBJECT_MANGLING.obj
>> "
>> "C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\object_mangling_imp.ob
>> j"
>> /Fe"C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\NO_OBJECT_MANGLING.
>> exe" /link  /NODEFAULTLIB:"msvcprtd.lib" /DEBUG"
>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42
>> for 80x86
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Microsoft (R) Incremental Linker Version 8.00.50727.42
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> /out:C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\NO_OBJECT_MANGLING
>> .exe /NODEFAULTLIB:msvcprtd.lib /DEBUG 
>> C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\NO_OBJECT_MANGLING.obj 
>> C:\Build\stdcxx-trunk\msvc-8.0\15d\include\tests\object_mangling_imp.obj
>>
>> NO_OBJECT_MANGLING.obj : error LNK2001: unresolved external symbol "int
>> declared_int_defined_char_array" (?declared_int_defined_char_array@@3HA)
>>
>>
>>> Actually, I should clarify that a bit more. The framework treats each
>>> .cpp file as an independent config test. Since you've added two .cpp
>>> files, the framework attempts to make them both like regular config
>>> tests. It tries to build them into executables and execute them.
>>>
>>> Travis
>>>
>>>> The framework will add the new test, but it doesn't have any way to 
>>>> know
>>>> to compile and link object_name_mangling_imp.o. Something will need to
>>>> be updated for that to work correctly.
>>>>
>>>> Travis
> 


Mime
View raw message