Mailing List Archive: [PATCH] Fix compilation with ncurses-devel-6.1

[PATCH] Fix compilation with ncurses-devel-6.1

Jan 11, 2020, 12:24 PM

Post #1 of 4 (649 views)

Another one (I can't remember if I sent it already, sorry if I did)

From 5d787a2ced5dffec75add2d07f5604c48d933b38 Mon Sep 17 00:00:00 2001
From: David Faure <faure@kde.org>
Date: Sun, 22 Jul 2018 23:56:48 +0200
Subject: [PATCH] Fix compilation with ncurses-devel-6.1

/usr/include/ncursesw/curses.h is evil and #defines ttytype.
---
pinentry/pinentry.h | 2 ++
1 file changed, 2 insertions(+)

diff --git a/pinentry/pinentry.h b/pinentry/pinentry.h
index 009e884..59d4f48 100644
--- a/pinentry/pinentry.h
+++ b/pinentry/pinentry.h
@@ -28,6 +28,8 @@ extern "C" {
#endif
#endif

+#undef ttytype
+
typedef enum {
PINENTRY_COLOR_NONE, PINENTRY_COLOR_DEFAULT,
PINENTRY_COLOR_BLACK, PINENTRY_COLOR_RED,
--
2.16.4

--
David Faure, faure@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] Fix compilation with ncurses-devel-6.1 [ In reply to ]

gniibe at fsij

Jan 13, 2020, 9:03 PM

Post #2 of 4 (647 views)

Permalink

Hello,

Just my comment to explain the situation.

David Faure <faure@kde.org> wrote:
> --- a/pinentry/pinentry.h
> +++ b/pinentry/pinentry.h
> @@ -28,6 +28,8 @@ extern "C" {
> #endif
> #endif
>
> +#undef ttytype
> +
> typedef enum {
> PINENTRY_COLOR_NONE, PINENTRY_COLOR_DEFAULT,
> PINENTRY_COLOR_BLACK, PINENTRY_COLOR_RED,
> --

I haven't had any experience with Ncurses 6.1, thus, I checked the
possible cause.

I realized that when Ncurses is built with --enable-reentrant, the
symbol "ttytype" will be a macro (to access per thread variable), which
conflicts the use case of pinentry's "ttytype", as a member in a struct.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Re: [PATCH] Fix compilation with ncurses-devel-6.1 [ In reply to ]

gnupg-devel at gnupg

Jan 16, 2020, 6:16 AM

Post #3 of 4 (640 views)

Permalink

Hi,

On Tuesday 14 January 2020 06:03:58 CET NIIBE Yutaka wrote:
> I haven't had any experience with Ncurses 6.1, thus, I checked the
> possible cause.
>
> I realized that when Ncurses is built with --enable-reentrant, the
> symbol "ttytype" will be a macro (to access per thread variable), which
> conflicts the use case of pinentry's "ttytype", as a member in a struct.

thanks NIIBE, what do you think, should we just apply the patch? I was not so
happy to just have an #undef in a header because depending on where you
include it it might break other things.

Best Regards,
Andre Heinecke

--
GnuPG.com - a brand of g10 Code, the GnuPG experts.

g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459
GF Werner Koch, USt-Id DE215605608, www.g10code.com.

GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf. VR 11482 D?sseldorf
Vorstand: W.Koch, M.Gollowitzer, A.Heinecke. Mail: board@gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-2104-4938799

Re: [PATCH] Fix compilation with ncurses-devel-6.1 [ In reply to ]

gniibe at fsij

Jan 20, 2020, 12:10 AM

Post #4 of 4 (637 views)

Permalink

Andre Heinecke wrote:
> On Tuesday 14 January 2020 06:03:58 CET NIIBE Yutaka wrote:
>> I haven't had any experience with Ncurses 6.1, thus, I checked the
>> possible cause.
>>
>> I realized that when Ncurses is built with --enable-reentrant, the
>> symbol "ttytype" will be a macro (to access per thread variable), which
>> conflicts the use case of pinentry's "ttytype", as a member in a struct.
>
> thanks NIIBE, what do you think, should we just apply the patch? I was not so
> happy to just have an #undef in a header because depending on where you
> include it it might break other things.

Currently, #undef-ing seems an easy choice for pinentry. If we want
something Right, we'd open a can of worms.

The best thing is that Ncurses will/would eventually offer a good
API/ABI with the use case of --enable-reentrant (in future). Then, the
users of Ncurses can keep existing code with no change. But it seems
difficult, because it will once again break the ABI.

Technically, it can be cleanly implemented with thread local variables
(of C11), but Ncurses already uses macros and functions to achieve that.
--

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

Mailing List Archive

Mailing List Archive

Attached Files: