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[2]: *** [Makefile:812: tr46map.lo] Error 1
Created attachment 477822 [details] output of emerge --info
Created attachment 477824 [details, diff] patch to fix ssize_t and error.h I found this patch on github [1] and it seems to work just fine for both amd64 and arm! 1 = https://github.com/morbith-dqtz/gentoo-musl-libressl
There has been a relevant commit [1] upstream. Does upgrading to version 2.0.2 maybe also fix the compilation issue for you? [1]: https://gitlab.com/libidn/libidn2/commit/1d61d402a662c8f9297177bd55afc8100d4717a1
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.
The <error.h> problem was fixed upstream in [1], 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. [1] https://gitlab.com/libidn/libidn2/commit/3eeaa280a7c28773d95a9b7c10d9f17596344480
So it is not possible to regenerate gnulib during prepare or configure?
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.
(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.
Can you open a bug for the stablization of 2.0.2 @Jeroen Roovers?
tt_1, you can open a stable request yourself: https://wiki.gentoo.org/wiki/Stable_request