|Summary:||=net-dns/libidn2-0.16-r1 with sys-libs/musl - tr46map.c: In function 'get_map_data': tr46map.c:162:11: error: 'ssize_t' undeclared (first use in this function)|
|Product:||Gentoo Linux||Reporter:||tt_1 <herrtimson>|
|Component:||Current packages||Assignee:||Jeroen Roovers (RETIRED) <jer>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
output of emerge --info
patch to fix ssize_t and error.h
Description tt_1 2017-06-24 08:25:40 UTC
Created attachment 477820 [details] build log net-libs/gnutls [idn] needs it. the compile error looks like tr46map.c: In function 'get_map_data': tr46map.c:162:11: error: 'ssize_t' undeclared (first use in this function) for (; (ssize_t) n > 0; n--) ^ tr46map.c:162:11: note: each undeclared identifier is reported only once for each function it appears in tr46map.c:162:20: error: expected ';' before 'n' for (; (ssize_t) n > 0; n--) ^ make: *** [Makefile:812: tr46map.lo] Error 1
Comment 2 tt_1 2017-06-24 08:32:48 UTC
Created attachment 477824 [details, diff] patch to fix ssize_t and error.h I found this patch on github  and it seems to work just fine for both amd64 and arm! 1 = https://github.com/morbith-dqtz/gentoo-musl-libressl
Comment 3 Felix Janda 2017-06-24 10:39:58 UTC
There has been a relevant commit  upstream. Does upgrading to version 2.0.2 maybe also fix the compilation issue for you? : https://gitlab.com/libidn/libidn2/commit/1d61d402a662c8f9297177bd55afc8100d4717a1
Comment 4 tt_1 2017-06-25 12:28:22 UTC
The upstream patch fixes the compile error which is about ssize_t , but there is another one due to the include of error.h and the lack of it in musl. I guess it would be possible to merge those patches somehow? =net-dns/libidn2-2.0.2 compiles without errors, but does not have stable keywords.
Comment 5 Felix Janda 2017-06-25 22:42:45 UTC
The <error.h> problem was fixed upstream in , however that patch cannot be used directly. (It would require regeneration of gnulib.) The patch attached to this bug would change the output of idn2 in error conditions (slightly). I think it makes more sense to ask for stabilization of the newer version of the package.  https://gitlab.com/libidn/libidn2/commit/3eeaa280a7c28773d95a9b7c10d9f17596344480
Comment 6 tt_1 2017-06-29 10:28:58 UTC
So it is not possible to regenerate gnulib during prepare or configure?
Comment 7 Felix Janda 2017-06-29 11:59:20 UTC
In pricinple, it is possible to regenerate gnulib. However this would definitely require a revbump which would need to be stabilized... So it seems easier to stabilize the new version.
Comment 8 Jeroen Roovers (RETIRED) 2017-06-30 07:34:01 UTC
(In reply to Felix Janda from comment #7) > In pricinple, it is possible to regenerate gnulib. However this would > definitely require a revbump which would need to be stabilized... > > So it seems easier to stabilize the new version. And it definitely should go stable.
Comment 9 tt_1 2017-06-30 07:58:46 UTC
Can you open a bug for the stablization of 2.0.2 @Jeroen Roovers?