From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30694 invoked by alias); 18 Jul 2008 20:17:19 -0000 Received: (qmail 30685 invoked by uid 22791); 18 Jul 2008 20:17:18 -0000 X-Spam-Check-By: sourceware.org Received: from ag-out-0708.google.com (HELO ag-out-0708.google.com) (72.14.246.243) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 20:16:59 +0000 Received: by ag-out-0708.google.com with SMTP id 26so9381792agb.12 for ; Fri, 18 Jul 2008 13:16:56 -0700 (PDT) Received: by 10.100.225.19 with SMTP id x19mr560060ang.146.1216412216780; Fri, 18 Jul 2008 13:16:56 -0700 (PDT) Received: from ?192.168.1.5? ( [200.161.1.30]) by mx.google.com with ESMTPS id c1sm1698440ana.26.2008.07.18.13.16.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Jul 2008 13:16:56 -0700 (PDT) Cc: gdb-patches@sourceware.org Message-Id: From: Dr. Rolf Jansen To: Pedro Alves In-Reply-To: <200807182032.31901.pedro@codesourcery.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Subject: Re: [gdbserver] compiling latest server.c (rev. 1.76) with MinGW for running on win32 Date: Fri, 18 Jul 2008 20:17:00 -0000 References: <200807182032.31901.pedro@codesourcery.com> X-Mailer: Apple Mail (2.928.1) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00369.txt.bz2 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 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 > > This bit be done with... > > #if HAVE_MALLOC_H > #include > #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