From: Pedro Alves <palves@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: bernd.edlinger@hotmail.de, gdb-patches@sourceware.org,
dje@google.com, vapier@gentoo.org
Subject: Re: [PATCH] Enable building GDB without installed libtermcap
Date: Thu, 26 Feb 2015 18:45:00 -0000 [thread overview]
Message-ID: <54EF69A5.3020902@redhat.com> (raw)
In-Reply-To: <83bnkg5z9q.fsf@gnu.org>
On 02/26/2015 06:00 PM, Eli Zaretskii wrote:
>> Date: Thu, 26 Feb 2015 17:48:06 +0000
>> From: Pedro Alves <palves@redhat.com>
>> CC: GDB Patches <gdb-patches@sourceware.org>, Doug Evans <dje@google.com>, Mike Frysinger <vapier@gentoo.org>
>>
>> My idea to work around that is to simply use __attribute__((weak)).
>> Of all supported hosts
>> (https://sourceware.org/gdb/wiki/Systems#Supported_Hosts),
>> Windows/PE/COFF would be the one that I'd be worried about WRT use of
>> weak, but the limited weak support in PE/COFF seems to work here. A
>> cross build using x86_64-w64-mingw32 on Fedora 20 builds fine with
>> this.
>
> With what version of GCC? Quick testing indicates that 4.8.1 supports
> that, but 3.4.2 doesn't.
Ah. This was:
gcc version 4.8.3 20140522 (Fedora MinGW 4.8.3-1.fc20) (GCC)
>
> Which version of GCC is the minimal one we want to support?
Hard to say at this point. I'd hope we'd move to requiring
something more recent than 3.4.x. From past discussions, I was
assuming we'd start by requiring 4.2 at least when finally require
C++.
> Or how about making this conditional on C++?
Some want to build with -fno-common, even in C mode. Given
that this stub file never needed these variables while it was
Windows-only, how about we simply not define the variables
if compiling for mingw/cygwin, but define them as weak
everywhere else? The worse that can happen is some host that
didn't use to build for lack of termcap will now fail to build
due to lack of weak. In practical terms, you just end up with
no gdb, just like before, so no worse.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-02-26 18:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <DUB118-W1951908395674D538A9BBDE4280@phx.gbl>
2015-02-23 16:06 ` Pedro Alves
2015-02-23 16:18 ` Pedro Alves
2015-02-23 19:27 ` Mike Frysinger
2015-02-23 19:44 ` Eli Zaretskii
2015-02-23 20:33 ` Mike Frysinger
2015-02-23 21:00 ` Eli Zaretskii
2015-02-24 18:18 ` Bernd Edlinger
2015-02-24 19:34 ` Mike Frysinger
2015-02-24 20:29 ` Doug Evans
2015-02-26 17:29 ` Pedro Alves
2015-02-26 17:48 ` Pedro Alves
2015-02-26 18:00 ` Eli Zaretskii
2015-02-26 18:45 ` Pedro Alves [this message]
2015-02-26 18:55 ` Eli Zaretskii
2015-02-26 19:14 ` Pedro Alves
2015-04-02 17:34 ` Bernd Edlinger
2015-04-06 11:42 ` Pedro Alves
2015-02-26 19:15 ` Bernd Edlinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54EF69A5.3020902@redhat.com \
--to=palves@redhat.com \
--cc=bernd.edlinger@hotmail.de \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox