RE: AW: boost ?!

[Duft Markus]

The initial reason for writing wgcc was, that we have tons and tons of unix 
software in-house, and need to port them to windows. We have our own build and 
distribution mechanism, and use much of autotools and libtool as well. To not 
break everything, i wrote wgcc, so that we are able to (under interix) use our 
mechanisms and the autotools on windows as well (even without the need to 
change makefiles much).
Some simple changes are allways required ;o) thats because of the really 
different concepts between compilers.

Of course i'd like wgcc to understand as m uch as possible! I'd love to see 
stdcxx built with wgcc by the way. But at the moment i have not really enough 
time to look into it. Don't know how much changes this would need.

Cheers, Markus

-----Original Message-----
From: Martin Sebor [mailto:address@hidden 
Sent: Wednesday, September 20, 2006 11:02 PM
To: address@hidden
Subject: Re: AW: boost ?!

Duft Markus wrote:
> OMG, i'm so blind...... I messed up 12d and 15d, maybe those should get other 
> names ;o) now it's all clear why it can't work....

Yes, container iterators have different types between debug and optimized 
builds, with std::string and std::vector being plain pointers for efficiency. 
This makes the two kinds of builds incompatible with one another.

> 
> Anyway thanks for your time, and sorry for messing around in here!

No problem. Glad you got it worked out.

Martin

PS I haven't played with wgcc too much yet but I like the concept.
In fact, I've been thinking about writing a similar tool for some time, one 
that would provide a uniform interface to all compilers (i.e., the same set of 
compiler options across all). Have you considered enhancing wgcc in this way?

> 
> Cheers, Markus
> 
> -----Ursprüngliche Nachricht-----
> Von: Duft Markus [mailto:address@hidden
> Gesendet: Dienstag, 19. September 2006 09:37
> An: address@hidden
> Betreff: AW: boost ?!
> 
> Hm, the struct thing was completely wrong, sorry....
> 
> Ok, i just digged a little into this:
> 
> For example one of the unresolved symbols is:
> 
> address@hidden@address@hidden@std@@address@hidden@2@@s
> td@@QAEPADXZ
> 
> Which would be:
> 
> __declspec(dllimport) public: char * __thiscall 
> std::basic_string<char,struct std::char_traits<char>,class 
> std::allocator<char> >::begin(void)
> 
> The Stdcxx library has symbols some symbols which are close:
> 
> address@hidden@address@hidden@std@@address@hidden@2@@s
> td@@address@hidden@address@hidden@std@@V?$
> address@hidden@2@@std@@address@hidden@@XZ
> 
> Which would be:
> 
> __imp_public: class __rw::__rw_debug_iter<class 
> std::basic_string<char,struct std::char_traits<char>,class 
> std::allocator<char> >,char *,char *> __thiscall 
> std::basic_string<char,struct std::char_traits<char>,class 
> std::allocator<char> >::begin(void)
> 
> I now think that somehow there is a problem with the headers thinking they 
> need to compile debug iterators (in build 15d!?) and when using the lib, they 
> think something else ;o// i looked at my config.h but there was nothing i 
> could see in there. I attached it, maybe you can see something.
> 
> Cheers, Markus
> 
> -----Ursprüngliche Nachricht-----
> Von: Martin Sebor [mailto:address@hidden
> Gesendet: Montag, 18. September 2006 17:34
> An: address@hidden
> Betreff: Re: boost ?!
> 
> Duft Markus wrote:
> 
>>Hey again!
>> 
>>I'm currently fighting to get boost compiled with stdcxx... ;o) It 
>>seems, that boost uses both char and wchar_t versions of methods from 
>>stdcxx, which at least seems to compile, but cannot link, since there 
>>is no wchar_t impl in the stdlib15d.lib/.dll. Now my question is: can 
>>i somehow use 15d and 15D together on windows, so that both kind of 
>>symbols are present?
> 
> 
> The difference between 15d and 15D is that the first is a 32-bit build type 
> (ILP32) while the second is a 64-bit or wide one (LLP64 on Windows). The 
> "wide" has nothing to do with wchar_t, it refers to the width of the data 
> type(s).
> 
> Stdcxx has full support for wchar_t as long as the compiler supports it. Keep 
> in mind that the MSVC /Zc:wchar_t option changes the type and mangling of 
> wchar_t and thus is a binary incompatible option.
> Programs that link with the library must be compiled with same setting of the 
> option as the library (i.e., both on or both off).
> 
> See http://msdn2.microsoft.com/en-us/library/dh8che7s.aspx
> 
> 
>>And there seem to be some differences from windows STL to this one in 
>>which files get included automatically from other includes and so on, 
>>since i need to explicitly include some files for some things to work 
>>(like std::hex and std::dec are not found, except i include istream or
>>so....)
> 
> 
> Stdcxx is much less promiscuous (i.e., a lot cleaner) than other 
> implementations of the C++ standard library when it comes to its headers 
> introducing unnecessary names into scope. std::hex and other manipulators are 
> required to be declared in the header <ios> and nowhere else so in order to 
> use them you must include that header.
> 
> Martin