On Thu, 24 Oct 2013, Volker Kuhlmann wrote:
On Sat 19 Oct 2013 09:06:48 NZDT +1300, Matwey V.
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
(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.
* 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
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
* 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
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
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 Biener <rguenther(a)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(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org