Re: [gdbserver] compiling latest server.c (rev. 1.76) with MinGW for running on win32

[Dr. Rolf Jansen <rolf.anroni@gmail.com>]

Hi Pedro,

many thanks for the reply!

Am 18.07.2008 um 16:32 schrieb Pedro Alves:

> Hi Rolf,
>
> On Friday 18 July 2008 18:32:32, Dr. Rolf Jansen wrote:
>> The latest server.c rev 1.76 does produce warnings when compiled with
>> the MinGW tools:
>>
>> ...
>>
>> MinGW defines alloca() in <malloc.h> and memmem() is not built-in. I
>> think this should eventually be addressed in the configure script,
>> however, as a quick fix, I added at the top of server.c:
>>
>>
>> #if USE_WIN32API
>> #include <malloc.h>
>
> This bit be done with...
>
> #if HAVE_MALLOC_H
> #include <malloc.h>
> #endif
>
> ... instead.  We're already doing that in utils.c.

YES, I can confirm this, this works for server.c too.

Great!

>> void *memmem (const void *haystack_start, size_t haystack_len, const
>> void *needle_start, size_t needle_len);
>> #endif
>
> Hmmm, shouldn't we be picking up memmem's definition from gnulib's  
> string.h,
> since we're using memmem from gnulib?

Ah, now I got it.

I fear gnulib's string.h will not work in my case, because I am  
compiling gdb at a Mac OS X box using the Mac gcc-4.2-tool chain with  
host=powerpc-apple-darwin9.4.0 and target=i386-mingw32msvc. And from  
the same source tree I am cross-compiling gdbserver using the MinGW- 
gcc-4.3.1-tool chain with build=powerpc-apple-darwin9.4.0 and host/ 
target=i386-pc-mingw32msvc.

Since gnulib belongs to the gdb source tree, and Mac OS X has memmem()  
and the other stuff built-in, gnulib's string.h would never be built.

This kind of issue with gnulib when compiling gdb and cross-compiling  
gdbserver was discussed recently already, and it only came back into  
my mind now. So, I am sorry about reporting a false issue.

In my local code I simply keep the declaration of memmem(), however it  
is probably not a good idea to patch HEAD.server.c with that.



>> In order to resolve the linking errors, the definition of the
>> respective variables must be moved out of the conditional block
>> (#ifdef SIGTTOU ... #endif), because they are used also within non-
>> conditional code in remote-utils.c and in server.c.
> Ooops.  Yes, it should move out of the #if block.  It was just an
> oversight.  No need to add the SIGTTOU checks around the
> --disable-packet handling.

OK, I took it out, and I confirm that this works too.

Best regards

Rolf Jansen