[Pkg-electronics-devel] A future for Newlib in Debian

[John Scott]

Hi all,

The Newlib package hasn't seen much activity, and I'd like to salvage
it. Before I file a formal ITS, I'd like to gauge opinions on what its
future looks like. I'm biased since I'm packaging gcc-sh-elf, and I'd
like to hear thoughts from those who are familiar with the gcc-arm-
none-eabi toolchain.

The way gcc-sh -elf works is that it builds GCC and Newlib packages
simultaneously using a combined tree. This is possible since my recent
NMU provides a newlib-source binary package. This has a couple nice
properties:

 - We avoid the bootstrap problem of needing parts of Newlib and GCC to
build each other. For example, at the moment gcc-arm-none-eabi appears
to not build libssp (which requires a target ISO C standard library) at
all, which is what provides the stack protection features.

 - If we build a simulator at the same time (from the GDB sources; I
believe it has one for ARM), we can actually run and test the bare-
metal binaries. Not only does this open up opportunities for robust
autopkgtests, but it actually enables running the GCC test suite, which
expects both being able to run the target binaries as well as (I
believe) an ISO C standard library.

I would like to see gcc-arm-none-eabi use newlib-source to build a
libnewlib-arm-none-eabi-dev package (libnewlib-dev is a misnomer), and
the Newlib source package be solely responsible for building libnewlib-
doc and newlib-source.

What are everyone's thoughts on this matter? I'm willing to put in the
work to make this happen, but I don't have any personal experience
using gcc-arm-none-eabi. I would also appreciate if someone could fill
me in as to why it's not using upstream GCC sources from gcc-11-source.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20211008/7d4e6df8/attachment.sig>