A new version was released a few months ago. Reproducible: Always
3.1.0 was released beginning of this year
This is needed for RISC-V cross-compilation support.
Out of curiosity what tuple you are interested in?
Tried to bump to newlib-3.1.0 today and stumbled on a build failure (same in -9999): """ make[9]: Entering directory '/tmp/portage/cross-arm-none-eabi/newlib-9999/work/build/arm-none-eabi/thumb/newlib/libc/machine/arm' arm-none-eabi-gcc -B/tmp/portage/cross-arm-none-eabi/newlib-9999/work/build/arm-none-eabi/thumb/newlib/ -isystem /tmp/portage/cross-arm-none-eabi/newlib-9999/work/build/arm-none-eabi/thumb/newlib/targ-include -isystem /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/include -B/tmp/portage/cross-arm-none-eabi/newlib-9999/work/build/arm-none-eabi/thumb/libgloss/arm -L/tmp/portage/cross-arm-none-eabi/newlib-9999/work/build/arm-none-eabi/thumb/libgloss/libnosys -L/tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/libgloss/arm -mthumb -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"3.1.0\" -DPACKAGE_STRING=\"newlib\ 3.1.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I/tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm -fno-builtin -D__SINGLE_THREAD__ -D__NO_SYSCALLS__ -D_COMPILING_NEWLIB -DHAVE_INIT_FINI --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=8192 -O2 -pipe -fdiagnostics-show-option -frecord-gcc-switches -Wall -Wextra -Wstack-protector -ffunction-sections -fdata-sections -mthumb -c -o lib_a-strcpy.o `test -f 'strcpy.c' || echo '/tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm/'`strcpy.c In file included from /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/include/ssp/strings.h:34, from /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/include/strings.h:77, from /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/include/string.h:24, from /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm/strcpy.c:31: /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm/strcpy.c:42:1: error: expected declaration specifiers or '...' before numeric constant 42 | strcpy (char* dst, const char* src) | ^~~~~~ In file included from /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/include/string.h:180, from /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm/strcpy.c:31: /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm/strcpy.c:42:1: error: expected ')' before '!=' token 42 | strcpy (char* dst, const char* src) | ^~~~~~ /tmp/portage/cross-arm-none-eabi/newlib-9999/work/newlib-9999/newlib/libc/machine/arm/strcpy.c:42:1: error: expected ')' before '?' token 42 | strcpy (char* dst, const char* src) | ^~~~~~ """ That comes from redefinition of local strcpy() symbols likely introduced in https://github.com/mirror/newlib-cygwin/commit/e4fc4d7bc47f5082a084415e237d39e40dd701be
Gentoo's gcc is a bit special in a way it injects _FORTIFY_SOURCE on everyone: https://gitweb.gentoo.org/proj/gcc-patches.git/tree/9.2.0/gentoo/01_all_default-fortify-source.patch This likely causes strcpy() definition to run on newlib's code itself.
The following workaround works (we might need more selective way to do it): --- a/sys-libs/newlib/newlib-9999.ebuild +++ b/sys-libs/newlib/newlib-9999.ebuild @@ -35,8 +35,8 @@ NEWLIBBUILD="${WORKDIR}/build" NEWLIBNANOBUILD="${WORKDIR}/build.nano" NEWLIBNANOTMPINSTALL="${WORKDIR}/nano_tmp_install" -CFLAGS_FULL="-ffunction-sections -fdata-sections" -CFLAGS_NANO="-Os -ffunction-sections -fdata-sections" +CFLAGS_FULL="-ffunction-sections -fdata-sections -U_FORTIFY_SOURCE" +CFLAGS_NANO="-Os -ffunction-sections -fdata-sections -U_FORTIFY_SOURCE" pkg_setup() { # Reject newlib-on-glibc type installs
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=25b326e873440a8bbb83a3734aeb6e839ef5d777 commit 25b326e873440a8bbb83a3734aeb6e839ef5d777 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-10-23 06:47:35 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-10-23 06:48:45 +0000 sys-libs/newlib: bump up to 3.1.0, bug #656018 Reported-by: David Flogeras Closes: https://bugs.gentoo.org/656018 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/newlib/Manifest | 1 + sys-libs/newlib/newlib-3.1.0.ebuild | 141 ++++++++++++++++++++++++++++++++++++ sys-libs/newlib/newlib-9999.ebuild | 16 ++-- 3 files changed, 151 insertions(+), 7 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=745e649426e2a012146ec5058817d02c30730937 commit 745e649426e2a012146ec5058817d02c30730937 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2023-01-20 22:28:01 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2023-01-20 22:29:34 +0000 sys-libs/newlib: drop -U_FORTIFY_SOURCE workaround The latest versions of newlib seem to build fine with this turned on, so drop the hack to see if there are any latent issues to fix upstream. Bug: https://bugs.gentoo.org/656018 Signed-off-by: Mike Frysinger <vapier@gentoo.org> sys-libs/newlib/newlib-9999.ebuild | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
