From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20511 invoked by alias); 2 Mar 2011 12:34:26 -0000 Received: (qmail 20164 invoked by uid 22791); 2 Mar 2011 12:34:25 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SARE_SUB_RAND_LETTRS4 X-Spam-Check-By: sourceware.org Received: from mail-qy0-f169.google.com (HELO mail-qy0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Mar 2011 12:34:20 +0000 Received: by qyk2 with SMTP id 2so4307756qyk.0 for ; Wed, 02 Mar 2011 04:34:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.183.193 with SMTP id ch1mr6474565qcb.107.1299069258276; Wed, 02 Mar 2011 04:34:18 -0800 (PST) Received: by 10.229.89.197 with HTTP; Wed, 2 Mar 2011 04:34:18 -0800 (PST) In-Reply-To: <20110302121407.GO30306@adacore.com> References: <4D6C90AC.9010003@codesourcery.com> <20110302121407.GO30306@adacore.com> Date: Wed, 02 Mar 2011 12:34:00 -0000 Message-ID: Subject: Re: Include dir intl when building libcommon.a for gdb From: Kai Tietz To: Joel Brobecker Cc: Yao Qi , gdb-patches@sourceware.org Content-Type: multipart/mixed; boundary=001485f78ec2adb282049d7f210f 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: 2011-03/txt/msg00087.txt.bz2 --001485f78ec2adb282049d7f210f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 4052 2011/3/2 Joel Brobecker : >> This patch is to fix this problem above. =A0Cross build gdb for >> i586-mingw32msvc. =A0Failure goes away. > > Thanks. I should say up-front that I appreciate your responsiveness. > It's very nice, particularly in this case where I feel the issue > is becoming more urgent to fix. > >> gdb/ >> =A0 =A0 =A0 * common/Makefile.in: Inherit CC. >> =A0 =A0 =A0 * common/configure.ac (GDB_INCLUDE): Include dir intl. >> =A0 =A0 =A0 * common/configure: Regenerate. > > Now, the bad news - Just this patch alone makes me dislike > the current approach. I'm really sorry, and maybe that's because > I'm not understanding all the issues, here. > >> diff --git a/gdb/common/Makefile.in b/gdb/common/Makefile.in >> index 9230b87..23117a9 100644 >> --- a/gdb/common/Makefile.in >> +++ b/gdb/common/Makefile.in >> @@ -26,6 +26,7 @@ COMMON_CPU_OBJ =3D @COMMON_CPU_OBJ@ >> =A0# CFLAGS is specifically reserved for setting from the command line >> =A0# when running make. =A0I.E. =A0"make CFLAGS=3D-Wmissing-prototypes". >> =A0CFLAGS =3D @CFLAGS@ >> +CC =3D @CC@ > > This part looks fairly obvious, and OK to me. > >> diff --git a/gdb/common/configure.ac b/gdb/common/configure.ac >> index 1ef85fe..b31a3e9 100644 >> --- a/gdb/common/configure.ac >> +++ b/gdb/common/configure.ac >> @@ -63,7 +63,7 @@ if test x"$enable_gdbserver" =3D xyes; then >> =A0 =A0GDB_INCLUDE=3D"-I\$(srcdir)/../gdbserver/" >> =A0else >> =A0 =A0GDB_FLAGS=3D"" >> - =A0GDB_INCLUDE=3D"-I\$(srcdir)/../ -I\$(BFD_DIR)" >> + =A0GDB_INCLUDE=3D"-I\$(srcdir)/../ -I\$(BFD_DIR) -I../../intl/" >> =A0fi > > This part, however, makes me uncomfortable. =A0There are a couple > of reasons. =A0The current code is: > > =A0 =A0if test x"$enable_gdbserver" =3D xyes; then > =A0 =A0 =A0GDB_FLAGS=3D"-DGDBSERVER" > =A0 =A0 =A0GDB_INCLUDE=3D"-I\$(srcdir)/../gdbserver/" > =A0 =A0else > =A0 =A0 =A0GDB_FLAGS=3D"" > =A0 =A0 =A0GDB_INCLUDE=3D"-I\$(srcdir)/../ -I\$(BFD_DIR)" > =A0 =A0fi > > The first question is: I don't understand why we have different > include and compilation flags. I can see how -DGDBSERVER is used > to select between gdb's "defs.h" and gdbserver's "server.h". So, > OK for now. =A0But for the rest, why do we maintain different include > paths depending on whether we build it for GDB or for GDBserver? > It's like a circular dependency. =A0I can explain that we need to > select either $(srcdir)/../gdbserver/ or $(srcdir)/../ for the > same reason as above (including "defs.h" or "server.h"). > > For the rest, I think that the -I flags should be the same regardless > of who we build these files for. In my mind, it's supposed to be > actually independent from both GDB and GDBserver. And unfortunately, > right now, it is dependent on both :-(. > > This definitely makes me rethink the way we approached the problem. > By taking what we have now, and moving it to common/, we drag some > dependencies which I think we do not want. I think we should either > strive to remove these dependencies as fast as we can, or use an > approach where we go the other way: Start with the foundations, and > then implement the things we are trying to move to common/ using > that foundation. =A0For instance, defs.h versus server.h. =A0It's tough > right now, because defs has more than just definitions. We could > isolate the part that provides the common non-GDB-specific definitions > into a common/common-defs. > > In the meantime, one proposed easy way out that doesn't destroy > all the work that has been done so far is to add all the -I > directories regardless of who we build libcommon for. =A0I think > it makes sense from a conceptual point of view, and it will also > help us avoid maintaining 2 lists. But maybe it doesn't work for > practical reasons. > > -- > Joel > Hmm, not sure if it helps. But this missing -I ../../intl bugged me already for a while. I used the following patch in Makefile.in in gdb/common/ and I've added it to the INCLUDES. ChangeLog * common/Makfile.in (INCLUDES): Add -I for intl. Regards, Kai --001485f78ec2adb282049d7f210f Content-Type: text/plain; charset=US-ASCII; name="unbreak_common.txt" Content-Disposition: attachment; filename="unbreak_common.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gks894t90 Content-length: 818 SW5kZXg6IGdkYi9jb21tb24vTWFrZWZpbGUuaW4KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gZ2RiLm9yaWcvY29tbW9uL01ha2VmaWxlLmluCTIwMTEt MDMtMDIgMTM6MjA6MjIuMDAwMDAwMDAwICswMTAwCisrKyBnZGIvY29tbW9u L01ha2VmaWxlLmluCTIwMTEtMDMtMDIgMTM6MjU6MDUuNTA5NzE5MTAwICsw MTAwCkBAIC0zMSw3ICszMSw3IEBAIEJGRF9ESVIgPSAuLi8uLi9iZmQKIEJG RF9TUkMgPSAkKHNyY2RpcikvJChCRkRfRElSKQogQkZEX0NGTEFHUyA9IC1J JChCRkRfRElSKSAtSSQoQkZEX1NSQykKIAotSU5DTFVERVMgPSAtSS4gLUku Li8gLUkkKHNyY2RpcikgLUkkKHNyY2RpcikvLi4vLi4vaW5jbHVkZSBAR0RC X0lOQ0xVREVACitJTkNMVURFUyA9IC1JLiAtSS4uLyAtSS4uLy4uL2ludGwg LUkkKHNyY2RpcikgLUkkKHNyY2RpcikvLi4vLi4vaW5jbHVkZSBAR0RCX0lO Q0xVREVACiAKIGxpYmNvbW1vbl9hX09CSlMgPSBzaWduYWxzLm8gJChDT01N T05fQ1BVX09CSikKIGxpYmNvbW1vbl9hX1NPVVJDRVMgPSBzaWduYWxzLmMg JChDT01NT05fQ1BVX1NSQykK --001485f78ec2adb282049d7f210f--