From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3300 invoked by alias); 14 Oct 2016 15:08:18 -0000 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 Received: (qmail 3257 invoked by uid 89); 14 Oct 2016 15:08:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=bear, gem, 1255 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Oct 2016 15:08:14 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1F23E6330D; Fri, 14 Oct 2016 15:08:13 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9EF8BVP008440; Fri, 14 Oct 2016 11:08:11 -0400 Subject: Re: Fix gdb 7.12 C++ compilation on Solaris To: Rainer Orth , gdb-patches@sourceware.org References: From: Pedro Alves Message-ID: <5e1396ea-6599-6b9a-bc8b-f59defaf4c3a@redhat.com> Date: Fri, 14 Oct 2016 15:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00449.txt.bz2 On 10/14/2016 03:45 PM, Rainer Orth wrote: > gdb 7.12 doesn't compile as C++ (tried with g++ 4.9) on Solaris (tried > 10 and 12, sparc and x86). The following patch (relative to the 7.12 > release, though I expect most if not all issues to be present on trunk, > too) fixes this. > > Only a few of the changes bear explanation: > > * Initially, compilation failed whereever defs.h. was included: > > In file included from /vol/src/gnu/gdb/gdb-7.12/gdb/gdb.c:19:0: > /vol/src/gnu/gdb/gdb-7.12/gdb/defs.h:630:33: error: 'double atof(const char*)' conflicts with a previous declaration > extern double atof (const char *); /* X3.159-1989 4.10.1.1 */ > ^ > In file included from /usr/include/stdlib.h:17:0, > from build-gnulib/import/stdlib.h:36, > from /vol/src/gnu/gdb/gdb-7.12/gdb/common/common-defs.h:32, > from /vol/src/gnu/gdb/gdb-7.12/gdb/defs.h:28, > from /vol/src/gnu/gdb/gdb-7.12/gdb/gdb.c:19: > /vol/gcc-4.9/lib/gcc/i386-pc-solaris2.10/4.9.0/include-fixed/iso/stdlib_iso.h:119:15: note: previous declaration 'double std::atof(const char*)' > extern double atof(const char *); > ^ > > This is due to this gem in gdb/defs.h which seems to have been present > like forever: > > #ifndef atof > extern double atof (const char *); /* X3.159-1989 4.10.1.1 */ > #endif > > In the Solaris headers, the appropriate functions are in namespace std, > thus the conflict. I've wrapped the defs.h declaration in !__cplusplus > to avoid this; perhaps it can go completely instead. master dropped support for building with a C compiler, it's C++-only. So for master, just delete the thing. On both branches, please delete the whole comment above as well: /* Global functions from other, non-gdb GNU thingies. Libiberty thingies are no longer declared here. We include libiberty.h above, instead. */ /* From other system libraries */ as it no longer makes any sense afterwards. > > * All the casts are necessary to appease g++ and should be pretty > obvious. > > * The sol-thread.c changes are here to handle > > /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c: In function 'void _initialize_sol_thread()': > /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c:1252:36: error: invalid conversion from 'void*' to 'void (*)(int)' [-fpermissive] > if (!(p_##X = dlsym (dlhandle, #X))) \ > ^ > /vol/src/gnu/gdb/gdb-7.12/gdb/sol-thread.c:1255:3: note: in expansion of macro 'resolve' > resolve (td_log); > ^ > > and are modeled after linux-thread-db.c (try_thread_db_load_1). > > The patch allowed both 32 and 64-bit C++ builds on sparc-sun-solaris2.10 > and i386-pc-solaris2.10 to complete. The resulting binary hasn't seen > more than a smoke test (invoke it on itself, b main, run) yet. > > Ok for mainline and 7.12 branch? Yes, with the tweak above on master. But, the process for getting fixes into the branch involves filing a PR. The reason is that the PR's subject is later used to help create the release announcement (manually). So please file a bug ("gdb 7.12 doesn't build on Solaris" or some such, and paste an example build error log). > Besides, when I compiled with g++ 4.9 installed into a non-default > location, gdb wouldn't run initially since libstdc++.so.6 and > libgcc_s.so.1 weren't found. Maybe it would be good to handle this as > gcc does and just link with -static-libstdc++ -static-libgcc? That's already included in the link line for me on GNU/Linux. Maybe it's host-specific? I've wondered before about why don't we use rpath instead though. Thanks, Pedro Alves