[Buildroot] [PATCH 1/1] util-linux: fix ncurses/wchar handling (again)

[Buildroot] [PATCH 1/1] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

util-linux #defines "wchar_t" as "char" when configured without widechar
support. This conflicts with definition of wchar_t contained in stddef.h,
so the compilation fails with

    error: two or more data types in declaration specifiers
    #define
     wchar_t char

The error can be reproduced rearrangin the incluson order in some files
under the text-utils directory.

Fixes:

  http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
  http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
  http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
---
 ...3-Fix-compilation-with-ncurses-and-uClibc.patch | 70 ++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch

diff --git a/package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch b/package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch
new file mode 100644
index 0000000..95f9e34
--- /dev/null
+++ b/package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch
@@ -0,0 +1,70 @@
+From bcad0c3629101aeafec266ecb0221cac0f52fcec Mon Sep 17 00:00:00 2001
+From: Carlos Santos <casantos@datacom.ind.br>
+Date: Fri, 13 Jan 2017 01:13:19 -0200
+Subject: [PATCH] Fix compilation with ncurses and uClibc
+
+Replacing "wchar_t" by "char" in widechar.h causes a conflict with the
+definition of wchar_t contained in stddef.h, which is included by c.h,
+so the compilation fails with
+
+   error: two or more data types in declaration specifiers #define
+   wchar_t char
+
+The error can be reproduced by configuring with --disable-widechar
+--without-ncursesw --with-ncurses. It can be avoided by moving the
+inclusion of widechar.h below the inclusion of c.h in colcrt.c,
+colrm.c and column.c.
+
+Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
+---
+ text-utils/colcrt.c | 2 +-
+ text-utils/colrm.c  | 2 +-
+ text-utils/column.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/text-utils/colcrt.c b/text-utils/colcrt.c
+index 62f8425..f376350 100644
+--- a/text-utils/colcrt.c
++++ b/text-utils/colcrt.c
+@@ -46,8 +46,8 @@
+ #include <getopt.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "closestream.h"
+ 
+ /*
+diff --git a/text-utils/colrm.c b/text-utils/colrm.c
+index 431eae0..e799cd1 100644
+--- a/text-utils/colrm.c
++++ b/text-utils/colrm.c
+@@ -44,9 +44,9 @@
+ #include <unistd.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "strutils.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "closestream.h"
+ 
+ /*
+diff --git a/text-utils/column.c b/text-utils/column.c
+index b8d31c9..e0144a2 100644
+--- a/text-utils/column.c
++++ b/text-utils/column.c
+@@ -50,8 +50,8 @@
+ #include <getopt.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "xalloc.h"
+ #include "strutils.h"
+ #include "closestream.h"
+-- 
+2.7.4
+
-- 
2.7.4

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

util-linux #defines "wchar_t" as "char" when configured without widechar
support. This conflicts with definition of wchar_t contained in stddef.h,
so the compilation fails with

    error: two or more data types in declaration specifiers
    #define
     wchar_t char

The error can be avoided by rearranging the inclusion order in some files
under the text-utils directory.

Fixes:

  http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
  http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
  http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>

---
Changes v1 -> v2
  - Fixed commit message (mental note: do not run "git commit" at 2:30 AM)

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
---
 ...3-Fix-compilation-with-ncurses-and-uClibc.patch | 70 ++++++++++++++++++++++
 1 file changed, 70 insertions(+)
 create mode 100644 package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch

diff --git a/package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch b/package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch
new file mode 100644
index 0000000..95f9e34
--- /dev/null
+++ b/package/util-linux/0003-Fix-compilation-with-ncurses-and-uClibc.patch
@@ -0,0 +1,70 @@
+From bcad0c3629101aeafec266ecb0221cac0f52fcec Mon Sep 17 00:00:00 2001
+From: Carlos Santos <casantos@datacom.ind.br>
+Date: Fri, 13 Jan 2017 01:13:19 -0200
+Subject: [PATCH] Fix compilation with ncurses and uClibc
+
+Replacing "wchar_t" by "char" in widechar.h causes a conflict with the
+definition of wchar_t contained in stddef.h, which is included by c.h,
+so the compilation fails with
+
+   error: two or more data types in declaration specifiers #define
+   wchar_t char
+
+The error can be reproduced by configuring with --disable-widechar
+--without-ncursesw --with-ncurses. It can be avoided by moving the
+inclusion of widechar.h below the inclusion of c.h in colcrt.c,
+colrm.c and column.c.
+
+Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
+---
+ text-utils/colcrt.c | 2 +-
+ text-utils/colrm.c  | 2 +-
+ text-utils/column.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/text-utils/colcrt.c b/text-utils/colcrt.c
+index 62f8425..f376350 100644
+--- a/text-utils/colcrt.c
++++ b/text-utils/colcrt.c
+@@ -46,8 +46,8 @@
+ #include <getopt.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "closestream.h"
+ 
+ /*
+diff --git a/text-utils/colrm.c b/text-utils/colrm.c
+index 431eae0..e799cd1 100644
+--- a/text-utils/colrm.c
++++ b/text-utils/colrm.c
+@@ -44,9 +44,9 @@
+ #include <unistd.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "strutils.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "closestream.h"
+ 
+ /*
+diff --git a/text-utils/column.c b/text-utils/column.c
+index b8d31c9..e0144a2 100644
+--- a/text-utils/column.c
++++ b/text-utils/column.c
+@@ -50,8 +50,8 @@
+ #include <getopt.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "xalloc.h"
+ #include "strutils.h"
+ #include "closestream.h"
+-- 
+2.7.4
+
-- 
2.7.4

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Thomas Petazzoni]

Hello,

On Fri, 13 Jan 2017 08:03:53 -0200, Carlos Santos wrote:
> util-linux #defines "wchar_t" as "char" when configured without widechar
> support. This conflicts with definition of wchar_t contained in stddef.h,
> so the compilation fails with
> 
>     error: two or more data types in declaration specifiers
>     #define
>      wchar_t char
> 
> The error can be avoided by rearranging the inclusion order in some files
> under the text-utils directory.
> 
> Fixes:
> 
>   http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
>   http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
>   http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941
> 
> Signed-off-by: Carlos Santos <casantos@datacom.ind.br>

I tried to fix the same problem in commit
5a18eabdf08564688761a9b2f35892d69d8f9a18, but apparently failed at
taking into account all the possible situations.

So if we are going to merge a different solution, I'd like to see an
investigation of whether commit
5a18eabdf08564688761a9b2f35892d69d8f9a18 is still needed or not. If
it's not, then it should be reverted as well.

I must say I find the fix of playing with the ordering of includes to
be somewhat hackish. Do we have a better solution? Is it really legal
for util-linux to redefine wchar_t? Should it use a better autoconf
check before doing this?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> To: "Carlos Santos" <casantos@datacom.ind.br>
> Cc: buildroot at buildroot.org
> Sent: Tuesday, January 17, 2017 3:44:37 AM
> Subject: Re: [Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

> Hello,
> 
> On Fri, 13 Jan 2017 08:03:53 -0200, Carlos Santos wrote:
>> util-linux #defines "wchar_t" as "char" when configured without widechar
>> support. This conflicts with definition of wchar_t contained in stddef.h,
>> so the compilation fails with
>> 
>>     error: two or more data types in declaration specifiers
>>     #define
>>      wchar_t char
>> 
>> The error can be avoided by rearranging the inclusion order in some files
>> under the text-utils directory.
>> 
>> Fixes:
>> 
>>   http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
>>   http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
>>   http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941
>> 
>> Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
> 
> I tried to fix the same problem in commit
> 5a18eabdf08564688761a9b2f35892d69d8f9a18, but apparently failed at
> taking into account all the possible situations.
> 
> So if we are going to merge a different solution, I'd like to see an
> investigation of whether commit
> 5a18eabdf08564688761a9b2f35892d69d8f9a18 is still needed or not. If
> it's not, then it should be reverted as well.

Ok, I will take a look tonight.

> I must say I find the fix of playing with the ordering of includes to
> be somewhat hackish. Do we have a better solution? Is it really legal
> for util-linux to redefine wchar_t? Should it use a better autoconf
> check before doing this?
> 
> Thomas

I'd rather disable ncurses support at all instead of resorting to ugly
hacks. Looks like ncurses is important for other people, however, so I
attempted to preserve it.

As far as I understand the redefinition aims to compile util-linux for
systems whose C libraries do not support wide characters at all (and
therefore do not define wchar_t). Perhaps this was easy to do a long
time ago but now that C compilers provide wchar_t as a built-in type
it became complicated.

Carlos Santos (Casantos) - DATACOM, P&D
?Something must be done. This is something. Therefore we must do it.?
(from the BBC series ?Yes, Prime Minister?, ?Power to the people?)

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Marcus Hoffmann]

On 17.01.2017 06:44, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 13 Jan 2017 08:03:53 -0200, Carlos Santos wrote:
>> util-linux #defines "wchar_t" as "char" when configured without widechar
>> support. This conflicts with definition of wchar_t contained in stddef.h,
>> so the compilation fails with
>>
>>     error: two or more data types in declaration specifiers
>>     #define
>>      wchar_t char
>>
>> The error can be avoided by rearranging the inclusion order in some files
>> under the text-utils directory.
>>
>> Fixes:
>>
>>   http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
>>   http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
>>   http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941
>>
>> Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
> 
> I tried to fix the same problem in commit
> 5a18eabdf08564688761a9b2f35892d69d8f9a18, but apparently failed at
> taking into account all the possible situations.
> 
> So if we are going to merge a different solution, I'd like to see an
> investigation of whether commit
> 5a18eabdf08564688761a9b2f35892d69d8f9a18 is still needed or not. If
> it's not, then it should be reverted as well.
> 
> I must say I find the fix of playing with the ordering of includes to
> be somewhat hackish. Do we have a better solution? Is it really legal
> for util-linux to redefine wchar_t? Should it use a better autoconf
> check before doing this?

Maybe we should ask the util-linux list? There's often an active
discussion, on what is the correct way to handle such things.

Marcus

> 
> Thomas
> 

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

> From: "Marcus Hoffmann" <m.hoffmann@cartelsol.com>
> To: buildroot at busybox.net
> Sent: Tuesday, January 17, 2017 11:57:12 AM
> Subject: Re: [Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

> On 17.01.2017 06:44, Thomas Petazzoni wrote:
>> Hello,
>> 
>> On Fri, 13 Jan 2017 08:03:53 -0200, Carlos Santos wrote:
>>> util-linux #defines "wchar_t" as "char" when configured without widechar
>>> support. This conflicts with definition of wchar_t contained in stddef.h,
>>> so the compilation fails with
>>>
>>>     error: two or more data types in declaration specifiers
>>>     #define
>>>      wchar_t char
>>>
>>> The error can be avoided by rearranging the inclusion order in some files
>>> under the text-utils directory.
>>>
>>> Fixes:
>>>
>>>   http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
>>>   http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
>>>   http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941
>>>
>>> Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
>> 
>> I tried to fix the same problem in commit
>> 5a18eabdf08564688761a9b2f35892d69d8f9a18, but apparently failed at
>> taking into account all the possible situations.
>> 
>> So if we are going to merge a different solution, I'd like to see an
>> investigation of whether commit
>> 5a18eabdf08564688761a9b2f35892d69d8f9a18 is still needed or not. If
>> it's not, then it should be reverted as well.

It can be reverted. I just confirmed that my patch covers both the
musl and uClibc cases.

>> I must say I find the fix of playing with the ordering of includes to
>> be somewhat hackish. Do we have a better solution? Is it really legal
>> for util-linux to redefine wchar_t? Should it use a better autoconf
>> check before doing this?
> 
> Maybe we should ask the util-linux list? There's often an active
> discussion, on what is the correct way to handle such things.
> 
> Marcus

I just sent a patch to the util-linux list.

Carlos Santos (Casantos) - DATACOM, P&D
?Something must be done. This is something. Therefore we must do it.?
(from the BBC series ?Yes, Prime Minister?, ?Power to the people?)

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

> From: "Carlos Santos" <casantos@datacom.ind.br>
> To: "Hoffmann, Marcus" <m.hoffmann@cartelsol.com>, "Petazzoni, Thomas" <thomas.petazzoni@free-electrons.com>
> Cc: buildroot at busybox.net
> Sent: Thursday, January 19, 2017 5:28:50 PM
> Subject: Re: [Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

>> From: "Marcus Hoffmann" <m.hoffmann@cartelsol.com>
>> To: buildroot at busybox.net
>> Sent: Tuesday, January 17, 2017 11:57:12 AM
>> Subject: Re: [Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling
>> (again)
> 
>> On 17.01.2017 06:44, Thomas Petazzoni wrote:
[...]
>>> So if we are going to merge a different solution, I'd like to see an
>>> investigation of whether commit
>>> 5a18eabdf08564688761a9b2f35892d69d8f9a18 is still needed or not. If
>>> it's not, then it should be reverted as well.
> 
> It can be reverted. I just confirmed that my patch covers both the
> musl and uClibc cases.
> 
>>> I must say I find the fix of playing with the ordering of includes to
>>> be somewhat hackish. Do we have a better solution? Is it really legal
>>> for util-linux to redefine wchar_t? Should it use a better autoconf
>>> check before doing this?
>> 
>> Maybe we should ask the util-linux list? There's often an active
>> discussion, on what is the correct way to handle such things.
>> 
>> Marcus
> 
> I just sent a patch to the util-linux list.

Good news! My patch was accepted and applied upstream:

    http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5

Carlos Santos (Casantos) - DATACOM, P&D
?Something must be done. This is something. Therefore we must do it.?
(from the BBC series ?Yes, Prime Minister?, ?Power to the people?)

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

> From: "Carlos Santos" <casantos@datacom.ind.br>
> To: "Marcus Hoffmann" <m.hoffmann@cartelsol.com>, "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> Cc: buildroot at busybox.net
> Sent: Friday, January 20, 2017 8:24:03 AM
> Subject: Re: [Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[...]

> Good news! My patch was accepted and applied upstream:
> 
>    http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5
> 

Hi,

Would a solution like this be considered too much hacky?

diff --git a/package/util-linux/util-linux.hash b/package/util-linux/util-linux.hash
index 4f19851..46b58f0 100644
--- a/package/util-linux/util-linux.hash
+++ b/package/util-linux/util-linux.hash
@@ -1,2 +1,4 @@
 # From https://www.kernel.org/pub/linux/utils/util-linux/v2.29/sha256sums.asc
 sha256 2c59ea67cc7b564104f60532f6e0a95fe17a91acb870ba8fd7e986f273abf9e7  util-linux-2.29.tar.xz
+# Locally computed
+sha256 d0c3ecc2d80106b65a005056baab4be78bf7184d25fae88aa358c65db54b578c  ?id=9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5
diff --git a/package/util-linux/util-linux.mk b/package/util-linux/util-linux.mk
index 51ece90..6140fe1 100644
--- a/package/util-linux/util-linux.mk
+++ b/package/util-linux/util-linux.mk
@@ -8,6 +8,7 @@ UTIL_LINUX_VERSION_MAJOR = 2.29
 UTIL_LINUX_VERSION = $(UTIL_LINUX_VERSION_MAJOR)
 UTIL_LINUX_SOURCE = util-linux-$(UTIL_LINUX_VERSION).tar.xz
 UTIL_LINUX_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/util-linux/v$(UTIL_LINUX_VERSION_MAJOR)
+UTIL_LINUX_PATCH = http://git.kernel.org/cgit/utils/util-linux/util-linux.git/patch/?id=9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5
 
 # For 0001-build-sys-prefer-pkg-config-for-ncurses.patch and
 # 0002-build-sys-cleanup-UL_NCURSES_CHECK.patch

The only disadvantage seems to be the ugly file name. I looked ad the download
support scripts and was unable to find a way to save with a more friendly name
like ?util-linux-9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5.patch?.

Carlos Santos (Casantos) - DATACOM, P&D
?Something must be done. This is something. Therefore we must do it.?
(from the BBC series ?Yes, Prime Minister?, ?Power to the people?)

[Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

> From: "Carlos Santos" <casantos@datacom.ind.br>
> To: "Marcus Hoffmann" <m.hoffmann@cartelsol.com>, "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> Cc: buildroot at busybox.net
> Sent: Saturday, January 21, 2017 6:52:55 PM
> Subject: Re: [Buildroot] [PATCH v2] util-linux: fix ncurses/wchar handling (again)
---8<---
> Hi,
> 
> Would a solution like this be considered too much hacky?
> 
> diff --git a/package/util-linux/util-linux.hash
> b/package/util-linux/util-linux.hash
> index 4f19851..46b58f0 100644
> --- a/package/util-linux/util-linux.hash
> +++ b/package/util-linux/util-linux.hash
> @@ -1,2 +1,4 @@
> # From https://www.kernel.org/pub/linux/utils/util-linux/v2.29/sha256sums.asc
> sha256 2c59ea67cc7b564104f60532f6e0a95fe17a91acb870ba8fd7e986f273abf9e7
> util-linux-2.29.tar.xz
> +# Locally computed
> +sha256 d0c3ecc2d80106b65a005056baab4be78bf7184d25fae88aa358c65db54b578c
> ?id=9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5
> diff --git a/package/util-linux/util-linux.mk b/package/util-linux/util-linux.mk
> index 51ece90..6140fe1 100644
> --- a/package/util-linux/util-linux.mk
> +++ b/package/util-linux/util-linux.mk
> @@ -8,6 +8,7 @@ UTIL_LINUX_VERSION_MAJOR = 2.29
> UTIL_LINUX_VERSION = $(UTIL_LINUX_VERSION_MAJOR)
> UTIL_LINUX_SOURCE = util-linux-$(UTIL_LINUX_VERSION).tar.xz
> UTIL_LINUX_SITE =
> $(BR2_KERNEL_MIRROR)/linux/utils/util-linux/v$(UTIL_LINUX_VERSION_MAJOR)
> +UTIL_LINUX_PATCH =
> http://git.kernel.org/cgit/utils/util-linux/util-linux.git/patch/?id=9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5
> 
> # For 0001-build-sys-prefer-pkg-config-for-ncurses.patch and
> # 0002-build-sys-cleanup-UL_NCURSES_CHECK.patch
> 
> The only disadvantage seems to be the ugly file name. I looked ad the download
> support scripts and was unable to find a way to save with a more friendly name
> like ?util-linux-9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5.patch?.

Answering to my own question: cgit accepts a request like

    http://git.kernel.org/cgit/utils/util-linux/util-linux.git/patch/9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5.patch

Carlos Santos (Casantos) - DATACOM, P&D
?Something must be done. This is something. Therefore we must do it.?
(from the BBC series ?Yes, Prime Minister?, ?Power to the people?)

[Buildroot] [PATCH v3 1/2] Revert "util-linux: fix ncurses/wchar handling"

[Carlos Santos]

This reverts commit 5a18eabdf08564688761a9b2f35892d69d8f9a18.

It did not take into account all the possible situations. A different fix
will be provided in a forthcomming patch.

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
---
 package/util-linux/Config.in     |  5 -----
 package/util-linux/util-linux.mk | 20 ++++++++++----------
 2 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/package/util-linux/Config.in b/package/util-linux/Config.in
index cfb2451..e957f84 100644
--- a/package/util-linux/Config.in
+++ b/package/util-linux/Config.in
@@ -207,7 +207,6 @@ config BR2_PACKAGE_UTIL_LINUX_MORE
 	bool "more"
 	depends on BR2_USE_MMU # fork()
 	select BR2_PACKAGE_NCURSES
-	select BR2_PACKAGE_NCURSES_WCHAR if BR2_USE_WCHAR
 	help
 	  File perusal filter for crt viewing
 
@@ -253,7 +252,6 @@ config BR2_PACKAGE_UTIL_LINUX_PG
 	bool "pg"
 	depends on BR2_USE_MMU # fork()
 	select BR2_PACKAGE_NCURSES
-	select BR2_PACKAGE_NCURSES_WCHAR if BR2_USE_WCHAR
 	help
 	  Browse pagewise through text files
 
@@ -300,7 +298,6 @@ config BR2_PACKAGE_UTIL_LINUX_SETPRIV
 config BR2_PACKAGE_UTIL_LINUX_SETTERM
 	bool "setterm"
 	select BR2_PACKAGE_NCURSES
-	select BR2_PACKAGE_NCURSES_WCHAR if BR2_USE_WCHAR
 	help
 	  Set terminal attributes
 
@@ -313,14 +310,12 @@ config BR2_PACKAGE_UTIL_LINUX_SWITCH_ROOT
 config BR2_PACKAGE_UTIL_LINUX_TUNELP
 	bool "tunelp"
 	select BR2_PACKAGE_NCURSES
-	select BR2_PACKAGE_NCURSES_WCHAR if BR2_USE_WCHAR
 	help
 	  Set various parameters for the lp device
 
 config BR2_PACKAGE_UTIL_LINUX_UL
 	bool "ul"
 	select BR2_PACKAGE_NCURSES
-	select BR2_PACKAGE_NCURSES_WCHAR if BR2_USE_WCHAR
 	help
 	  Do underlining
 
diff --git a/package/util-linux/util-linux.mk b/package/util-linux/util-linux.mk
index 414465c..51ece90 100644
--- a/package/util-linux/util-linux.mk
+++ b/package/util-linux/util-linux.mk
@@ -45,21 +45,21 @@ ifeq ($(BR2_PACKAGE_BUSYBOX),y)
 UTIL_LINUX_DEPENDENCIES += busybox
 endif
 
-ifeq ($(BR2_USE_WCHAR),y)
-UTIL_LINUX_CONF_OPTS += --enable-widechar
-else
-UTIL_LINUX_CONF_OPTS += --disable-widechar
-endif
-
-ifeq ($(BR2_PACKAGE_NCURSES_WCHAR),y)
+ifeq ($(BR2_PACKAGE_NCURSES),y)
 UTIL_LINUX_DEPENDENCIES += ncurses
+ifeq ($(BR2_PACKAGE_NCURSES_WCHAR),y)
 UTIL_LINUX_CONF_OPTS += --with-ncursesw
 UTIL_LINUX_CONF_ENV += NCURSESW5_CONFIG=$(STAGING_DIR)/usr/bin/$(NCURSES_CONFIG_SCRIPTS)
-else ifeq ($(BR2_PACKAGE_NCURSES):$(BR2_USE_WCHAR),y:)
-UTIL_LINUX_DEPENDENCIES += ncurses
-UTIL_LINUX_CONF_OPTS += --without-ncursesw --with-ncurses
+else
+UTIL_LINUX_CONF_OPTS += --without-ncursesw --with-ncurses --disable-widechar
 UTIL_LINUX_CONF_ENV += NCURSES5_CONFIG=$(STAGING_DIR)/usr/bin/$(NCURSES_CONFIG_SCRIPTS)
+endif
+else
+ifeq ($(BR2_USE_WCHAR),y)
+UTIL_LINUX_CONF_OPTS += --enable-widechar
 else
+UTIL_LINUX_CONF_OPTS += --disable-widechar
+endif
 UTIL_LINUX_CONF_OPTS += --without-ncursesw --without-ncurses
 endif
 
-- 
2.7.4

[Buildroot] [PATCH v3 2/2] util-linux: fix ncurses/wchar handling (again)

[Carlos Santos]

Since commit 006a328ad6bed214ec3c4d92120510ea37329dd1 ("util-linux: fix
build with ncurses"), we have a build failure that occurs with musl and
uClibc-ng toolchains when wide-char support is not enabled in ncurses.

The problem occurs because util-linux #defines its own wchar_t (as char)
when configured without widechar support. It was fixed upstream, so pull
the corresponding patch from the util-linux git repository.

Fixes:
  http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
  http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
  http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941
  http://autobuild.buildroot.net/results/8a9e197ba7a292b18f8c0c36dca974685556a38a

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>

---
Changes v1 -> v2
  - Fixed commit message (mental note: do not run "git commit" at 2:30 AM)
Changes v2 -> v3
  - Pull the patch from the util-linux git repository
  - Simplify commit message

Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
---
 ...ix-compilation-with-ncurses-and-uClibc-or.patch | 92 ++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 package/util-linux/0003-build-sys-fix-compilation-with-ncurses-and-uClibc-or.patch

diff --git a/package/util-linux/0003-build-sys-fix-compilation-with-ncurses-and-uClibc-or.patch b/package/util-linux/0003-build-sys-fix-compilation-with-ncurses-and-uClibc-or.patch
new file mode 100644
index 0000000..2a1e56d
--- /dev/null
+++ b/package/util-linux/0003-build-sys-fix-compilation-with-ncurses-and-uClibc-or.patch
@@ -0,0 +1,92 @@
+From 9ea8ded37b648bbd538cbf9c4d144b8b1a93c1b5 Mon Sep 17 00:00:00 2001
+From: Carlos Santos <casantos@datacom.ind.br>
+Date: Thu, 19 Jan 2017 17:27:37 -0200
+Subject: [PATCH] build-sys: fix compilation with ncurses and uClibc or musl
+ libc
+
+Compiling util-linux with musl and uClibc-ng toolchains when wide-char
+support is not enabled in ncurses results in compilation failures with
+the following message:
+
+    error: two or more data types in declaration specifiers
+    #define
+     wchar_t char
+
+The problem occurs because util-linux #defines its own wchar_t (as char)
+when configured without widechar support. This conflicts with definition
+of wchar_t contained in stddef.h.
+
+This error can be reproduced running "<toolchain-cc -o test test.c" with
+the following test program:
+
+    #include <ctype.h>
+    #define wchar_t char
+    #include <stddef.h>
+
+    int main()
+    {
+        return 0;
+    }
+
+The only way to avoid the problem it to reorder the inclusion of headers
+in some files under the text-utils directory.
+
+Addresses:
+  http://autobuild.buildroot.net/results/3a2f228e0fa7b5cc28a13d49f48f1a6aef8d9d7a
+  http://autobuild.buildroot.net/results/99e96069f652d511c6212a5bb6be29e68fb1747c
+  http://autobuild.buildroot.net/results/2dc5721aef93b7b410153bafad78248fac3db941
+  http://autobuild.buildroot.net/results/8a9e197ba7a292b18f8c0c36dca974685556a38a
+
+Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
+---
+ text-utils/colcrt.c | 2 +-
+ text-utils/colrm.c  | 2 +-
+ text-utils/column.c | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/text-utils/colcrt.c b/text-utils/colcrt.c
+index c6bba4b..346a10f 100644
+--- a/text-utils/colcrt.c
++++ b/text-utils/colcrt.c
+@@ -46,8 +46,8 @@
+ #include <getopt.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "closestream.h"
+ 
+ /*
+diff --git a/text-utils/colrm.c b/text-utils/colrm.c
+index 9510b72..d474696 100644
+--- a/text-utils/colrm.c
++++ b/text-utils/colrm.c
+@@ -44,9 +44,9 @@
+ #include <unistd.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "strutils.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "closestream.h"
+ 
+ /*
+diff --git a/text-utils/column.c b/text-utils/column.c
+index 43b3af5..2eb47a3 100644
+--- a/text-utils/column.c
++++ b/text-utils/column.c
+@@ -50,8 +50,8 @@
+ #include <getopt.h>
+ 
+ #include "nls.h"
+-#include "widechar.h"
+ #include "c.h"
++#include "widechar.h"
+ #include "xalloc.h"
+ #include "strutils.h"
+ #include "closestream.h"
+-- 
+2.7.4
+
-- 
2.7.4

[Buildroot] [PATCH v3 1/2] Revert "util-linux: fix ncurses/wchar handling"

[Thomas Petazzoni]

Hello,

On Sun, 22 Jan 2017 01:15:41 -0200, Carlos Santos wrote:
> This reverts commit 5a18eabdf08564688761a9b2f35892d69d8f9a18.
> 
> It did not take into account all the possible situations. A different fix
> will be provided in a forthcomming patch.
> 
> Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
> ---
>  package/util-linux/Config.in     |  5 -----
>  package/util-linux/util-linux.mk | 20 ++++++++++----------
>  2 files changed, 10 insertions(+), 15 deletions(-)

Both applied to master. Let's see if it really fixes all the
problems :-)

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com