Re: [wgcc-dev] wgcc does not build

[Martin K. <mk...@gm...>]

Hi Markus,

> I wrote wgcc with the main intention to get native windows binaries that
> are plain win32 and have nothing to do anymore with any unix subsystem
> or something, since this gave lots of problems, especially with
> debugging. For example try to build wgcc debuggable with gcc and debug
> with gdb -> it's really impossible ;o)

yes, that's a problem. :-(

> Debugging with visual studio is really cool only when building really
> native (linking with link.exe) maybe the best woulb be building with gcc
> and linking with link.exe.

agreed here, too.

To continue my last mail for motivations for creating POSIX-CUI 
exes with MS tools, I have these:

- One could have link.exe via wgcc as drop-in replacement for ld, 
which is buggy in some situations. (Of course then there is only 
static linking...)

- gcc/g++ 3.3 is rather old now, so cl.exe could be used, e.g. instead 
of g++ to have better C++ support.


> If you look at the source code of wgcc it would be not a big problem
> implementing alternative compiler/linker tasks, since everything is
> really modular.

sounds good.

> At the moment i don't have enough time to work on this, but i will take
> a look at it in the near future, since it sounds promising and desirable
> to make wgcc able of using the interix tools too. This would make wgcc
> the most powerfull build tool for interix around (and most configurable
> one)...
>
> I played around with wgcc and ld, and it seems to work for a small hello
> world.... Really cool would have been beeing able of using msvcrt libc
> when linking with ld, but there seem to be some restriction, since i
> can't seem to be able to execute the resulting binary (but link goes ok
> without even a warning)...
>
> As far as i now see, using either ld or gcc forces the use of the
> interix libc & co. This is for our (company) current situation not
> really desireable as i allready said, but since wgcc is an open source
> project i'm willing to spend some time in implementing this anyway -
> when i got some time ;o)

Thank you. Can you approximately say, when this might happen?

> As far as building bash & co. With cl.exe is concerned: be aware of
> compiler capability differences... For example gcc uses
> __atribute__(...) and MS uses __declspec(...) which each other don't
> understand. So the sources will most likely not build. One more thing
> is, that you would have to first port libtermcap or libncurses or so to
> cl.exe, which as far as i know would be _really much_ work...

>From gcc-4.1 docs:
You can use __declspec(dllexport) as a synonym for __attribute__ 
((dllexport)) for compatibility with other compilers.

But: for .so files, you don't need any of __attribute__ or __declspec. 
.so libs are not DLLs! I currently don't know much technical detail, 
but they are different. That's why only ld can link (to) them. The 
general idea is of course the same, though.

See here for some details:
http://www.interopsystems.com/tools/tm.aspx?m=7904

>> Many questions ;o) maybe you want to try (after wgcc works ;o)) to 
>> only compile with wgcc, and manually link with ld and gather some 
>> experience in this direction.... I will try too!
>
> Ok, will try with wgcc, too.

This doesn't work, because wgcc compiles with Win32 libc headers, so 
gcc/ld complains when linking:

$ wgcc -g -c -o hello.o hello.c
$ gcc hello.o
hello.o(.text+0xc): undefined reference to `__imp__printf'
collect2: ld returned 1 exit status

Martin