Re: [boost] wgcc 2.0 RC1 released

From: Duft Markus (Markus.Duft_at_[hidden])
Date: 2006-09-20 05:07:42

All i can talk of is my experience using interix, since i didn't use
cygwin that much. Cygwin was more or less dead at out company when i
came in. The yhad too much problems with the cygwin builds. Some of the
problems are, that the w32api for cygwin and mingw is not the *real*
w32api, but some own thing they built. I really don't know how this
w32api behaves, or if it has any drawbacks.
As for gdb, the version that comes with interix 3.5 is from
i-don't-know-when (seems like year 2k or something), so many years old.
Maybe newer versions would work better. Debugging C code is not a
problem, everything works fine there, but never try to debug C++, you'll
get 10 lines far or so (until first using a STL string.....) ;o)
As of the import/export problems with MS, wgcc really does a lot in this
direction, one can say most of it's code is just for those problems. And
i think it manages to push things in the right direction. One has to
_only_ put __declspec(dllimport) in place where needed, and that _only_
for Data symbols. There is no need to differenciate static and shared
libraries, just put the import everywhere ;o) wgcc manages the rest.

-----Original Message-----
From: libtool-bounces+markus.duft=salomon.at_at_[hidden]
[mailto:libtool-bounces+markus.duft=salomon.at_at_[hidden]] On Behalf Of
Brendon Costa
Sent: Wednesday, September 20, 2006 10:43 AM
To: David Abrahams
Cc: boost_at_[hidden]; libtool_at_[hidden]
Subject: Re: [boost] wgcc 2.0 RC1 released

David Abrahams wrote:
> "Duft Markus" <Markus.Duft_at_[hidden]> writes:
> 
>> When building with wgcc there are a few benefits:
>>
>> Wgcc uses the native windows compiler to build (so the code may or 
>> may not be faster ;o)) and whats a lot more important: the debug 
>> information produced is readable by visual studio, so you can debug 
>> the output. Gdb on windows (at least on interix) is so terribly 
>> broken, i could not debug 10 lines of code without gdb failing at 
>> some point.
> 
> Works great for me under Cygwin, especially through emacs.

Code may not be faster. It really depends on the implementation of the
compiler. The differences would be negligible from my understanding,
though with more resources MS may be able to optimise some things in
their compiler... I don't know.

I do prefer the MS debugger, but my experience with GDB is that it also
works fine in windows (Under Cygwin and with MSYS/MinGW) and achieves
its purpose well enough (I guess not using emacs is part of my problem
:-) as it seems a little more clunky to use having to type in all these
breakpoints... I need a GUI frontend for GDB i think...)

>> The second thing is, that resulting executables depend on msvcrt.lib 
>> and are therefore binary compatible with nearly everything ;o) on 
>> windows.
> 
> That's also true of MinGW, right?

Yes. MinGW depends on msvcrt.lib

>> When using gcc it has it's own libc (on interix gcc is a interix 
>> build, and has really not much to do with windows.... ;o//) and one 
>> can't link those things together, so in gcc built binaries one can 
>> _not_ use the win32 API which, on windows, is not really desireable.
> 
> Huh?  Not so; I have used the win32 API even through cygwin GCC.
> And then there's gcc -mno-cygwin.

Yep. There is a win32api library for cygwin. Same as MinGW really with
-mno-cygwin i think...

>> The last thing is, that tools such as Rational Purify may be used to 
>> examine the resulting binaries. It's all just really native ;o)
>>
>> I'm really overwhelmed that someone outside my company finally shows 
>> at least _some_ interest. It's really cool, give it a try!
> 
> Not sure what I'm missing here, but at this point I don't see why I 
> should bother.  The existing tools work for me and are 
> well-established, with good support.
> 

One possible reason I can think of is that in the non-free world...
Sometimes a company might distribute a C++ library + some header files
(Without any source code). I have encountered this before. Since the ABI
is not the same between MSVC and MinGW/GCC it forces you to use the
compiler they have created the libraries using (Unless it is a pure C
interface) and if you have a desire to use the autotools build framework
(autoconf/automake/libtool) then this could be useful.

Having a wrapper for MSVC that behaves like gcc would mean that you can
use the autotools (A particulary important part of it is libtool for
this discussion) build framework with the MSVC compiler. This may be
beneficial in some situations instead of using the MSVC build
environment.

I tried cccl a while ago and shortly discovered a HEAP of issues
especially trying to compile things using libtool. So i went and started
my own shell script wrapper that improved on cccl. It got a fair way but
i was not willing to put more time into it and being a shell script like
libtool it slows compiling down a bit on large projects. Plus there is
no way to fix the auto import problem with MSVC. So i gave up on that
line of thought. From my understanding, wgcc is a compiled wrapper
similar to cccl but it has had a lot more features put into it so it
better "emulates" gcc. This has got advantages though is not suitable in
a lot of situations.

Instead of using a wrapper for the compiler/linker i have just started
using a different build toolset from automake/libtool. Jam and Scons are
two good examples that can use either compiler without having to force
the usage of MSVC to behave like gcc.

Anyhows, Thats just my two cents worth on the subject...

Brendon.

_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool