MingW32...

[Tim Angus]

On Thu, 22 Sep 2005 00:25:33 -0400 Ryan wrote:
> A couple of comments, brought about by the big-ass Mingw32 patch that
> just showed up in Subversion unannounced...

I announce it on IRC :P. (#icculus.org/quake3).

> There is this:
> 
> +    // The only difference is _ added to the C symbols. It seems
> mingw +    // mangles all symbols this way, like linux gcc does when
> producing +    // a.out instead of elf
> 
> In the GCC case, you should either use the
> __attribute__((alias("_sym"))) format to make sure we find the right
> thing:

Hmm, good idea. I dicked about with __attribute__s a little when I was
trying to figure out what was preventing it from compiling/running, but
it didn't occur to me to use them this way.

>  __asm__("_doAsmCall:  \n\t"
>          "doAsmCall:  \n\t"
> 	 "	movl (%%edi),%eax  \n\t"

This only works in this instance, i.e. C referencing an asm symbol. The
asm also references C symbols, and obviously you can't try calling
multiple symbols until it works. Therefore, the alias solution seems
preferable.

> There are a couple of these around the codebase:
> 
> #if !( (defined __linux__ || __FreeBSD__ || __MINGW32__) && (defined
> __i386__) && (!defined C_ONLY)) //
> 
> Can we replace all this nonsense with either a check for __GNUC__?
> This is only going to get uglier with each new platform, and be error
> prone for the ones that are missed.

That seems sensible.

> "3. Find the following in DXSDK/Include/dinput.h..."
> 
> Ugh, we have to modify a system header?!

Yeah, stupid isn't it? Some cretinous Microsoft engineer has typedefed
the same thing twice in the header. It's not like it's even that
obscure, they're right next to each other -- perhaps this is generated
code. In any case, while MSVC merrily compiles the multiple typedefs
without complaining, gcc shits a brick.

Two things occur to me:

1) Perhaps there is a way of convincing gcc to allow the multiple
typedefs with some GNU C preproccesor voodoo surrounding the #include
<dinput.h> line.
2) Presumably wine(lib) has equivalents of the required headers that are
correct enough to work. If such headers exist, they could probably be
included with ioQ3, which saves a lot of hassle.