libctf compilation failure on MinGW

libctf compilation failure on MinGW

[Eli Zaretskii]

Nick,

We had a conversation about this back in February, AFAIR, and your
conclusion was that you'd like to remove those E* constants from the
sources, and thus avoid the problem altogether.

Did you have time to make those changes since then?

GDB is about to branch for the imminent GDB 10.1 release, and
currently the problems I described back then are still with us.  So
we'd like a solution soon, and need to decide whether to go with the
same workaround we used for GDB 9.1 or use a better change from you.

Thanks in advance.

Re: libctf compilation failure on MinGW

[Nick Alcock]

On 2 Jul 2020, Eli Zaretskii outgrape:

> We had a conversation about this back in February, AFAIR, and your
> conclusion was that you'd like to remove those E* constants from the
> sources, and thus avoid the problem altogether.
>
> Did you have time to make those changes since then?

I... tried. It's *so annoying* to use that I'm going to go for your
original approach, and just #define undefined-on-some-platform E*
constants as needed. (Maybe I should automate this, and scan *all* E*
constants used by libctf in configure and define suitable replacements,
to avoid the whack-a-mole nature of this?)

> GDB is about to branch for the imminent GDB 10.1 release, and
> currently the problems I described back then are still with us.

Oh, I thought you pushed a fix already! Sorry!

I'll post a fix sticking suitable E* #defines in once I get back from
holiday on Tuesday.

> we'd like a solution soon, and need to decide whether to go with the
> same workaround we used for GDB 9.1 or use a better change from you.

I think that workaround is in hindsight better than the change I
proposed, and should go in trunk. :/

Re: libctf compilation failure on MinGW

[Eli Zaretskii]

> From: Nick Alcock <nick.alcock@oracle.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sourceware.org
> Date: Sat, 04 Jul 2020 19:16:22 +0100
> 
> > GDB is about to branch for the imminent GDB 10.1 release, and
> > currently the problems I described back then are still with us.
> 
> Oh, I thought you pushed a fix already! Sorry!

We did, but only on the-then GDB 9.1 branch.  The master branch wasn't
changed, as we expected to have you update the upstream with the
proper solution.

> I'll post a fix sticking suitable E* #defines in once I get back from
> holiday on Tuesday.
> 
> > we'd like a solution soon, and need to decide whether to go with the
> > same workaround we used for GDB 9.1 or use a better change from you.
> 
> I think that workaround is in hindsight better than the change I
> proposed, and should go in trunk. :/

Thanks.

Re: libctf compilation failure on MinGW

[Joel Brobecker]

Hi Nick,

On Sat, Jul 04, 2020 at 07:16:22PM +0100, Nick Alcock wrote:
> On 2 Jul 2020, Eli Zaretskii outgrape:
> 
> > We had a conversation about this back in February, AFAIR, and your
> > conclusion was that you'd like to remove those E* constants from the
> > sources, and thus avoid the problem altogether.
> >
> > Did you have time to make those changes since then?
> 
> I... tried. It's *so annoying* to use that I'm going to go for your
> original approach, and just #define undefined-on-some-platform E*
> constants as needed. (Maybe I should automate this, and scan *all* E*
> constants used by libctf in configure and define suitable replacements,
> to avoid the whack-a-mole nature of this?)
> 
> > GDB is about to branch for the imminent GDB 10.1 release, and
> > currently the problems I described back then are still with us.
> 
> Oh, I thought you pushed a fix already! Sorry!
> 
> I'll post a fix sticking suitable E* #defines in once I get back from
> holiday on Tuesday.
> 
> > we'd like a solution soon, and need to decide whether to go with the
> > same workaround we used for GDB 9.1 or use a better change from you.
> 
> I think that workaround is in hindsight better than the change I
> proposed, and should go in trunk. :/

I don't think the fix has been pushed, has it?  Would it help if
we pushed the fix we proposed a while back?

-- 
Joel