libctf compilation failure on MinGW

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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.
Reply | Threaded
Open this post in threaded view
|

Re: libctf compilation failure on MinGW

Sourceware - gdb-patches mailing list
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. :/
Reply | Threaded
Open this post in threaded view
|

Re: libctf compilation failure on MinGW

Eli Zaretskii
> From: Nick Alcock <[hidden email]>
> Cc: Joel Brobecker <[hidden email]>, [hidden email]
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: libctf compilation failure on MinGW

Joel Brobecker
In reply to this post by Sourceware - gdb-patches mailing list
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