Mailinglist Archive: opensuse-factory (498 mails)

< Previous Next >
[opensuse-factory] Re: New package: newlib
On Sat, 14 May 2016, Andreas Färber wrote:


Newlib [1] is a C standard library (i.e., alternative to glibc).

It is needed for two scenarios:

1) Compiling C software for non-Linux platforms, including
microcontrollers and bootloaders. It has originally been tested with an
Adapteva Epiphany target [2], as well as Renesas RX and RL78 [3, 4]
targets. With downstream patches it has been built for TI PRU [5].
In this scenario a host-only GCC (-bootstrap) is built without target
libraries to cross-compile static Newlib target libraries which are then
used to build the full GCC with cross-compiled libraries.

2) Bootstrapping other cross-compilers. Some other C standard libraries
form a full circular dependency with GCC libraries. For native builds
OBS takes care to break such a cycle; for cross targets Newlib can be
used as intermediate step. First a host-only GCC (-bootstrap) is built,
then Newlib, then GCC against Newlib (-mini), then the actual standard
library and finally the full GCC. This has been tested for both uClibc
(armv7ml [6]) and glibc (mipsel, mips64) toolchains.

What is not really needed is this "newlib" package... In theory an i686
shared library could be built, but in practice these days it chokes on
GCC's host headers, e.g., not finding __GNUC_PREREQ() macro. I can't
imagine a real use case for this on openSUSE, and not being available
for x86_64 anyway I don't think it's worth blocking on any longer.

newlib serves as source package that further cross-*-newlib-devel.spec
files can be generated in and _link'ed (similar to dtb-source package).

The gcc5 and gcc6 packages [7, 8] are already prepared for newlib.

The spec files used for testing specific cross-compilers have been
dropped from newlib for now, as there is a two-step dependency between
gccX and newlib, avoiding unresolvable build requirements in staging.

My suggestion is to merge this newlib stub package first. We can then
branch newlib to devel:gcc, prepare gcc5 and/or gcc6 cross packages
there and then submit gccX and newlib packages alongside through one
staging project.

Alternatively we could first submit cross-*-gccX-bootstrap packages that
don't depend on cross-*-newlib-devel packages yet, but they would be of
little use on their own and should rather not get published (similar to
systemd-mini package).

An oSC16 lightning talk [9] is planned with an update on this topic.

First of all thanks for continuing to work on this.

I have an issue with putting additional crosses into devel:gcc via
the gcc5 or gcc6 source packages. Factory submissions require that
all .spec files linking to the main package build which is quite a
burden already with some of the "stupid" crosses we have. Adding
in newlib crosses both increases build time and introduces new
failure paths I would have to deal with.

This is probably a more general issue of multiple .spec files
refering to the same source. I don't like the idea of splitting
the source itself too much but eventually I will start doing this
if things become too uncomfortable. That is, have a cross-gcc-source
"stub" package aggregating all the cross spec files.

In devel:gcc that could be a branch of the gcc package but in factory
it would be two different packages.




Richard Biener <rguenther@xxxxxxx>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
< Previous Next >
Follow Ups