From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5375 invoked by alias); 13 Sep 2008 17:08:58 -0000 Received: (qmail 5066 invoked by uid 22791); 13 Sep 2008 17:08:57 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Sep 2008 17:08:19 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D65F12A96BB for ; Sat, 13 Sep 2008 13:08:17 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pwVqQ0nLhbvJ for ; Sat, 13 Sep 2008 13:08:17 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6DB392A96B3 for ; Sat, 13 Sep 2008 13:08:17 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id ECA37E7ACD; Sat, 13 Sep 2008 10:08:14 -0700 (PDT) Date: Sat, 13 Sep 2008 17:08:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA/RFC] libdecnumber/gstdint.h is back :-( Message-ID: <20080913170814.GG3714@adacore.com> References: <20080913050011.GA3727@adacore.com> <20080913141335.GA3005@caradoc.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <20080913141335.GA3005@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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-09/txt/msg00293.txt.bz2 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1601 > Why does ../libdecnumber/gstdint.h exist? Is it because you're > configuring in the source directory, and if so can we just tell people > not to do that? Yes, I like doing my builds in-tree. I tried changing my habits to building out-of-tree, but having source files and generated files in different trees is sometimes a pain, so I ended up reverting to my old habits. If this is going to cause too much trouble, then I'll try to change my habits again. (Note: If this is the case, then we need to adjust the README file, which still mentions both options). > Another option would be to add a check for _GL_STDINT_H to > libdecnumber; I suspect they would not mind. In the same category, here is the temporary change I installed in our tree. I called it a horrible hack, but maybe that was an overstatement... > > What occured to me while thinking about all this is that the > > root of the problem is that we have two incompatible files that > > should be identical in practice. Since we are always building > > libdecnumber, can we use libdecnumber's gstdint.h and ditch > > gnulib's stdint.h? > > This could be a problem if we pulled in gnulib modules that > include from a replacement header. We already use > it in the building of gnulib (str-two-way.h). And I am also wondering about building gdbserver without configuring GDB - that might be a problem too. I can rework a little the comment, but what do you think of the idea? I think it's similar to your suggestion, except that the knowledge is kept on the "client" side rather than the library side. Thanks, -- Joel --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stdint.diff" Content-length: 1795 Modified: gdb/defs.h =================================================================== --- gdb/defs.h 2008-09-13 01:57:56 UTC (rev 135288) +++ gdb/defs.h 2008-09-13 04:09:52 UTC (rev 135289) @@ -30,6 +30,31 @@ #include #include +/* The libdecnumber library, on which GDB depends, includes a header file + called gstdint.h instead of relying directly on stdint.h. GDB, on the + other hand, includes stdint.h directly, relying on the fact that gnulib + generates a copy if the system doesn't provide one or if it is missing + some features. Unfortunately, gstdint.h and stdint.h cannot be included + at the same time, which may happen when we include a file from + libdecnumber. + + The first time we encountered this problem, we thought we had resolved + it by having a file named gstdint.h in this directory that would simply + contain a #include of stdint.h, thus hoping to "redirect" the gstdint.h + include in libdecnumber. Unfortunately, it turns out that this doesn't + work after all, mostly because libdecnumber includes gstdint.h using + the double quotes as opposed to the angle brackets. The search path + in implementation defined, but it seems that the gstdint.h files in + libdecnumber is picked up after all, thus defeating our trick. + + The following macro definition is a horrible hack that prevents + the effective inclusion of gstdint.h, as all the definitions it + provides are guarded against GCC_GENERATED_STDINT_H. We already + have gnulib/stdint.h included, so it's ok to blank out gstdint.h. + It's horrible but it allows to fix the build issues it gstdint.h + causes while we work on a more suitable fix. */ +#define GCC_GENERATED_STDINT_H 1 + #ifdef HAVE_STDDEF_H #include #endif --NzB8fVQJ5HfG6fxh--