On Thu, 24 Oct 2013, Volker Kuhlmann wrote:
On Sat 19 Oct 2013 09:06:48 NZDT +1300, Matwey V. Kornilov wrote:
Why we just don't have cross-avr-gcc48.spec in devel:gcc gcc48 like every other arch does? It is interesting that Factory supplies cross-avr-binutils but not cross-avr-gcc. May I try to push avr-support to devel:gcc?
Let's discuss the issues to be solved a bit more first. I did a LOT of work creating oS packages, because the default AVR compiler is antiquated and newer gcc offer much better optimisations and the introduction of LTO, and I wanted to play with that. Of course newer gcc may have different bugs that could upset the Arduino community expectations so installing multiple gcc versions is required.
The existing spec files needed improving in many areas and I am quite particular that this work is kept for any merge with mainline gcc:
* Having multiple avr-gcc versions installed and ready to run is non-negotiable. One expects the default version to be in PATH as avr-gcc. I have put all into PATH as avr-gcc-xyz, and provided a script run-avr-gcc-xyz that puts this version into PATH first, so run-avr-gcc-xyz avr-gcc -v gives the selected version. (This is needed, unless you want to be editing makefiles, the arduino IDE and everything else in use each time you want to try a different version.)
We do that for non-cross GCC packages already by suffixing binaries with -4.8 for example. So you'd have avr-gcc-4.8 for example. Not sure if --program-suffix works for cross compiler builds, it's currently disabled in our spec file though (that isn't a requirement though).
* /opt is been obsoleted some time ago. Use /usr.
* The "cross-" package name prefix has no useful purpose. In fact I find it a PITA. Traditions may be all well, but I strictly stop where they give me nothing and only waste my time. The host package is called "gcc", "avr-gcc" already says everything that needs to be said. (Anyone needing another "cross-" in front of that shouldn't be running that sort of software... ;-) )
As you like ... but best done per target. Requires cross-communication with binutils (and changes there) to get BuildRequires correct.
* Wrapper scripts for each of the avr-gcc etc for adjusting paths are mind-bogglingly broken. This emergency quick fix can be axed. https://bugzilla.novell.com/show_bug.cgi?id=767294
* Contrary to popular belief, building avr-gcc does NOT require avr-libc! Please fix build dependencies. Otherwise, how are you going to build avr-libc when you don't have a compiler to build it with? (Sure there are ways, but why not use the easy one.)
Well, whatever is "required" - you can surely build a avr-elf freestanding compiler. Not sure if there are any optional features enabled for GCC when building against avr-libc.
I have put the spec files and additional source files here (read the comments): http://volker.top.geek.nz/arduino/tools/suse12.3/ The spec file is appropriately commented, please keep the comments, they are there for a reason and building cross compilers has many pitfalls.
The avr-binutils are already in the OSS repo and derived from single-source. Good. Please work on its maintainer to drop the "cross-" prefix. I assume this is because the cross-compiler issue arose because of a need to build oS for ARM. avr-gcc is not in OSS, perhaps it's on someone's TODO but not there yet.
Issues for AVR users/maintainers for moving binutils and gcc in with the host packages:
* Less maintenance work overall, no duplicated efforts.
* How does the multi-version requirement integrate?
* AVR users may require changes more frequently. Is this going to become more difficult because host-gcc maintainers rightfully keep close control over changes potentially affecting openSUSE x86?
* Does merging with host-gcc put pressure on AVR users regarding choice of gcc version? Choice of binutils version? Patches to avr-binutils, avr-gcc? It has been necessary in the past to patch bugs in avr-binutils that prevented use of some optimisations by gcc. AVR users need to retain this ability. There have been many patches to avr-gcc as well, most required. The suggestion by avr-gcc developers always is to upgrade gcc, but there are issues of tool-environment stability against that. Arduino still uses stone-age by default - this is common with embedded systems where investments in tool evaluation are high and essential.
* Does this merge make it more difficult to make newer gcc releases for AVR available for evaluation?
I am all for leveraging the work already done by host-gcc maintainers. Can it be done with the extra requirements outlined above?
Most of it is not difficult, it just needs somebody do 1) do it, 2) test it. I can help with 1) if you tell me what avr build-requires (in addition to avr-binutils) and what extra configure arguments you need (compared to the "stock" cross-compiler flags we use in the host gcc package). For 2) I rely on others. Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org