Hello, 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. Regards, Andreas [1] https://build.opensuse.org/request/show/395228 [2] https://build.opensuse.org/project/show/home:a_faerber:epiphany [3] https://build.opensuse.org/project/show/home:a_faerber:rx [4] https://build.opensuse.org/project/show/home:a_faerber:rl78 [5] https://build.opensuse.org/project/show/home:a_faerber:pru [6] https://build.opensuse.org/project/show/home:a_faerber:uclinux [7] https://build.opensuse.org/package/show/devel:gcc/gcc5 [8] https://build.opensuse.org/package/show/devel:gcc/gcc6 [9] https://events.opensuse.org/conference/oSC16/program/proposal/918 -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org