[opensuse-factory] New package: newlib
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
Hi Andreas, sounds great so far, thanks for working on this. I really would like to see embeded development on openSUSE become mainline. Currently it is some stuff available in CrossToolchain:XXX, some stuff in different home: repositories, and some stuff completely missing. As far as I understand your current work would be usable also for arm-none- eabi toolchains, e.g. for the STM32Fxxx series? Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Stefan, Thanks. Kudos also go to Richie for his old gcc49 Hackweek project for openSUSE glibc targets, without which I wouldn't have come this far. Am 15.05.2016 um 19:11 schrieb Stefan Bruens:
As far as I understand your current work would be usable also for arm-none- eabi toolchains, e.g. for the STM32Fxxx series?
First of all, I had demonstrated back in 2014 that it's possible to use our armv7l gcc on an ARM board for developing for STM32F429 [1] under some constraints, namely the lack of a suitable libgcc. For U-Boot I had to enable (and tweak) its private libgcc copy; Linux built fine; and as bootloader I created my own afboot-stm32 [2] that was trivial enough not to have the libgcc dependency in the first place. If you need a linker script, feel free to use mine as template. One could probably use qemu-linux-user to run a native armv7hl gcc in a chroot on x86_64, but it'll be cumbersome and slow. Now for cross-compiling I believe we're still stuck with just one cross-arm-binutils, which does not work for cross-armv7hl-gcc5 (boo#936463) - the safest solution seems duplicating binutils packages to match the name gcc expects and offering a separate sysroot. For uClibc I therefore SR'ed binutils to allow, e.g., armv7ml-uclibc as target name, so in theory arm-none should be possible, too. You would probably also want multilib support for such targets, i.e. multiple copies of libraries to cope with Cortex-M0 vs. M3 vs. M4F etc. But my plan is to start with some simple target like Epiphany and move on to more complicated ones such as ARM later. :) The biggest hurdle has been gcc being a moving target, with its changing tarball names frequently breaking branches for new targets. Another issue has been about target installation, where gcc built okay but some target files ended up in an x86_64 lib64 subdirectory where they were not searched for 32-bit targets. If you want to play with it, note that while you can branch binutils as cross-foo-binutils and newlib as cross-foo-newlib-devel to add your target, you must branch gcc5 as gcc5 and create a project-local link for cross-foo-gcc5. Cheers, Andreas [1] https://en.opensuse.org/openSUSE:ARM_Tech_Symposia_2014/STM32F429 [2] https://github.com/afaerber/afboot-stm32 -- 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
On Sat, 14 May 2016, Andreas Färber wrote:
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.
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. Thanks, Richard.
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
--
Richard Biener
Am 19.05.2016 um 13:12 schrieb Richard Biener:
On Sat, 14 May 2016, Andreas Färber wrote:
Hello,
Newlib [1] is a C standard library (i.e., alternative to glibc). [...] 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.
I don't mind you splitting your package, but FTR let me say that in the ~year that I've been building these cross packages I've never had a build failure that was not due to the tarball file name changing (and thus resolved by re-running my branched pre_checkin.sh - an issue we wouldn't have in devel:gcc) or a general build breakage of gcc5. I.e., zero failures due to newlib so far. Of course that's not a guarantee for the future. I agree this shouldn't hold up native compiler updates unnecessarily. On the other hand though any major gcc updates (gcc5, gcc6) go through long-term staging projects that would probably allow fixing any cross-compilation issues alongside. And if there's a breakage you could still comment out the broken targets in change_spec until someone fixes them. More specifically if we add cross-compilers to gcc5 today then gcc6 doesn't have them unless someone makes an SR to gcc6, which should require to have successfully built it first. My main concern is that I would like to base our cross-compilers on a current and maintained gccX package, whether directly or indirectly. We already have separately packaged cross-compilers bit-rotting in CrossToolchain:sh4 and CrossToolchain:mingw:test and really don't need the same thing in devel:gcc. So if a branched cross-gcc5-source package breaks due to a gcc5 package update, aren't the effects the same as if we do it from gcc5 like today? Or would you want to keep cross-gcc-source completely separate (no _link) from gcc5/gcc6? Who would update it in that case and when? Also for clarity, IMO non-upstream targets such as pru would need to stay in a separate project, to not break updating - similar to how our kernel packages don't contain random downstream patchsets. Regards, Andreas
In devel:gcc that could be a branch of the gcc package but in factory it would be two different packages.
Thanks, Richard.
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
On Thu, 19 May 2016, Andreas Färber wrote:
Am 19.05.2016 um 13:12 schrieb Richard Biener:
On Sat, 14 May 2016, Andreas Färber wrote:
Hello,
Newlib [1] is a C standard library (i.e., alternative to glibc). [...] 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.
I don't mind you splitting your package, but FTR let me say that in the ~year that I've been building these cross packages I've never had a build failure that was not due to the tarball file name changing (and thus resolved by re-running my branched pre_checkin.sh - an issue we wouldn't have in devel:gcc) or a general build breakage of gcc5. I.e., zero failures due to newlib so far.
It's definitely not something I'll do immediately but only in case it becomes a problem for me when maintaining GCC.
Of course that's not a guarantee for the future. I agree this shouldn't hold up native compiler updates unnecessarily. On the other hand though any major gcc updates (gcc5, gcc6) go through long-term staging projects that would probably allow fixing any cross-compilation issues alongside. And if there's a breakage you could still comment out the broken targets in change_spec until someone fixes them. More specifically if we add cross-compilers to gcc5 today then gcc6 doesn't have them unless someone makes an SR to gcc6, which should require to have successfully built it first.
My main concern is that I would like to base our cross-compilers on a current and maintained gccX package, whether directly or indirectly. We already have separately packaged cross-compilers bit-rotting in CrossToolchain:sh4 and CrossToolchain:mingw:test and really don't need the same thing in devel:gcc. So if a branched cross-gcc5-source package breaks due to a gcc5 package update, aren't the effects the same as if we do it from gcc5 like today? Or would you want to keep cross-gcc-source completely separate (no _link) from gcc5/gcc6? Who would update it in that case and when?
I would make it a branch in devel:gcc but _not_ a branch/link in Factory (thus have another devel project that is not a branch of the factor package - gdb is/used to be another). The advantage is that sources stay in sync but factory sumbission of the core 'gcc' does not depend on submission of the cross packages.
Also for clarity, IMO non-upstream targets such as pru would need to stay in a separate project, to not break updating - similar to how our kernel packages don't contain random downstream patchsets.
Of course.
Richard.
--
Richard Biener
participants (3)
-
Andreas Färber -
Richard Biener -
Stefan Bruens