0.0.7.2 fails to build on arm with gcc6 (i.e. C++14)

[mtasaka]

0.0.7.2 fails to build on armv7hl with gcc 6 development version on Fedora 24 as https://kojipkgs.fedoraproject.org//work/tasks/6081/12886081/build.log

In file included from unf/normalizer.hh:10:0,
                 from unf.cc:1:
unf/table.hh:13539:25: error: narrowing conversion of '-27' from 'int' to 'char' inside { } [-Wnarrowing]
  -77, -39,-124, -39,-123};
                         ^
unf/table.hh:13539:25: error: narrowing conversion of '-113' from 'int' to 'char' inside { } [-Wnarrowing]
unf/table.hh:13539:25: error: narrowing conversion of '-81' from 'int' to 'char' inside { } [-Wnarrowing]
unf/table.hh:13539:25: error: narrowing conversion of '-27' from 'int' to 'char' inside { } [-Wnarrowing]
(and many others)

Note that gcc6 faults to -std=gnu++14, and "char" on arm is "unsigned" by default. So converting -113 (for example) to char on arm is narrowing conversion and C++11 prohibits this on initializer.

[mrohnstock]

Same here with Arch Linux ARM (armv7hl, too). gcc got updated to 6.1.1 and this error-messages occurred.

[andreas-schwab]

https://build.opensuse.org/package/live_build_log/OBS:Server:Unstable/rubygem-unf_ext/openSUSE_Factory_ARM/aarch64
https://build.opensuse.org/package/live_build_log/OBS:Server:Unstable/rubygem-unf_ext/openSUSE_Factory_PPC/ppc64le
https://build.opensuse.org/package/live_build_log/OBS:Server:Unstable/rubygem-unf_ext/openSUSE_Factory_zSystems/s390x

[Darkhogg]

Seems like there are multiple fixes for this issue, but the bug is still there. Any news?

[zatherz]

Bump. Same here on Raspberry Pi running Arch ARM.

[zatherz]

Nevermind. Turns out the fix is just not in the official release on rubygems yet, so the version you install through gem install doesn't have the fix. You have to build it from git.

[vielmetti]

Same problem on ARMv8, I'll try the install from git.

[vielmetti]

What will it take to get this change pushed into the official rubygems?

This comes up in the context of mastodon/mastodon#802 (port of Mastodon to ARM) with a Docker build.

[knu]

I'll look into this later today.

[mtasaka]

For now Fedora (me) has applied the following patch:
http://pkgs.fedoraproject.org/cgit/rpms/rubygem-unf_ext.git/tree/unf_ext-0.0.7.2-char-signness.patch

[vielmetti]

Thanks @knu @mtasaka . My target for this is a Packet 2A ARMv8 server running Docker, Alpine 3.5, and Ruby for Mastodon.

[ss89]

This also affects building gitlab ce on armhf.

[vielmetti]

@ss89 - is there an upstream issue for the gitlab build problem?

There was a report from the Mastodon project that this can be worked around by pulling the gem from git as a temporary measure pending a new release. I don't have the precise invocation necessary but it should be a simple and compatible one-liner.

[ss89]

@vielmetti i couldn't find any issue about it in their gitlab instance which they use for hosting the gitlab ce repo.

[ss89]

@knu I have a strange problem that might or might not be related to this one.
If you see this gist:
https://gist.github.com/ss89/14d1e90663dbac285b84cabaf60efeab
you will see that unf_ext was successfully built, but later when build crack it fails with the same error seen in the issue creators first post.
Should i create a new Issue for this?

[marcust]

@knu (/cc @vielmetti)
I was trying today to build that on arm64, but I got somehow the same build problems that used to be there before fee5abd was merged because d0947ba reintroduced the old typing, which is as far as I can see also in v0.0.7.3.

Or did I get something wrong?

[nomoon]

@marcust It looks like the ARM-fixed const signed char STRINGS[] in table.hh reverted to const char STRINGS[] in the Unicode 9.0 update. If I'm reading it correctly, the other types are still the same between both versions.

[nomoon]

I think #30 should be all that's necessary to fix it. @marcust are you able to test it via git?