Bug 238705 - Review Request: avr-gcc - Cross Compiling GNU GCC targeted at avr
Review Request: avr-gcc - Cross Compiling GNU GCC targeted at avr
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-02 10:11 EDT by Hans de Goede
Modified: 2010-07-12 13:08 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-23 10:42:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rc040203: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
improved specfile (4.75 KB, text/plain)
2007-05-20 11:00 EDT, Hans de Goede
no flags Details

  None (edit)
Description Hans de Goede 2007-05-02 10:11:02 EDT
Spec URL: http://people.atrpms.net/~hdegoede/avr-gcc.spec
SRPM URL: http://people.atrpms.net/~hdegoede/avr-gcc-4.1.2-2.fc7.src.rpm
Description:
This is a Cross Compiling version of GNU GCC, which can be used to
compile for the avr platform, instead of for the
native %{_arch} platform.
Comment 1 Ralf Corsepius 2007-05-02 10:29:32 EDT
Several questions based on visual inspection of the spec:

* Why are you using "make all-gcc" and "make install-gcc" instead of "make all"
and "make install"?

* Did you consider to split gcc and gcc-c++?
Mixing c and c++ into one package when many users of embedded system will only
use c implies a pretty ugly package bloat on them.

* If I am informed correctly (I am only semi-educated on the avr toolchain), the
classical avr toolchain is based on avr-libc. This would imply to build GCC
against avr libc instead of "no libc".
Comment 2 Hans de Goede 2007-05-02 10:41:09 EDT
(In reply to comment #1)
> Several questions based on visual inspection of the spec:
> 
> * Why are you using "make all-gcc" and "make install-gcc" instead of "make all"
> and "make install"?
> 

Good question, I don't know my students wrote the initial version and used this.
Unless they can give me a good reason I'll revert to the normal make targets.

> * Did you consider to split gcc and gcc-c++?
> Mixing c and c++ into one package when many users of embedded system will only
> use c implies a pretty ugly package bloat on them.
> 

I didn't think about this, a very good point I'll put them in a sub package.

> * If I am informed correctly (I am only semi-educated on the avr toolchain), the
> classical avr toolchain is based on avr-libc. This would imply to build GCC
> against avr libc instead of "no libc".

AFAIK the 2-stage building of gcc is not necessary for the AVR, none of the docs
on compiling gcc for the AVR I could find talk about this. See for example:
http://www.nongnu.org/avr-libc/user-manual/install_tools.html

Re-reading this page, I do notice that I forgot to add these 2 adviced configure
flags: "--disable-libssp --with-dwarf2". Unless someone objects I'll add these,
although I think --with-dwarf2 is only needed under windows for AVRStudio
compatibility though, so I'm not sure if thats needed for us.
Comment 4 Ralf Corsepius 2007-05-02 10:59:56 EDT
(In reply to comment #2)
> (In reply to comment #1)

> > * If I am informed correctly (I am only semi-educated on the avr toolchain), the
> > classical avr toolchain is based on avr-libc. This would imply to build GCC
> > against avr libc instead of "no libc".
> 
> AFAIK the 2-stage building of gcc is not necessary for the AVR, none of the docs
> on compiling gcc for the AVR I could find talk about this. See for example:
> http://www.nongnu.org/avr-libc/user-manual/install_tools.html
Well, normally, GCC checks for libc features and configures several of its
internal components accordingly (esp. wrt. target libraries such as libstdc++).

When none of the libc features can be found in libc, features will be disabled
("not found" == "not available") or be substituted ("not found" == "to be
provided"). This issue often is referred to as "bootstrapping GCC".

The standard way to work around this issue normally is to
first build an "initial bootstrap c-only gcc", then use this to build libc and
then to rebuild GCC. 

Another approach is "incrementally building", i.e. initially build a "bare
metal/libc-less GCC" (Which is what you currently build).
Install this, then build libc and then build a fullfledged GCC again.
Afterwards, all subsequent builds of avr-gcc would have to "BuildRequire:
avr-libc" and correctly receive the settings inside of avr-libc.

i.e. I am having strong doubts on the way of building GCC as being described
under the link above.

> Re-reading this page, I do notice that I forgot to add these 2 adviced configure
> flags: "--disable-libssp  --with-dwarf2". Unless someone objects I'll add these,
I don't know off-head (I could check the sources) if these are required by
"plain avr" targets.

Normally, if a target is properly implemented, none of them should be necessary,
but GCC internally should choose the correct option by itself
Comment 5 Ralf Corsepius 2007-05-02 11:17:21 EDT
Building exposes one of my "very friends" of bugs in rpm:
...
/usr/bin/strip: Unable to recognise the format of the input file
...

To work around this issue I am rewriting %__os_install_post.
(Details to be found in my rtems*gcc*specs.).
Comment 6 Hans de Goede 2007-05-02 11:19:01 EDT
Notice that the link above is THE install manual of THE libc for avr. Also avr
has (rudimentary) C++ support, but no libstdc++ support. Its libc also has no
threading support etc. This is a microcontroller environment with as little as
512 bytes of total RAM (not Kbytes but bytes! including space for the stack).
Thus most of the gcc features which require libc support simply do not apply.

Also see:
http://gcc.gnu.org/install/specific.html#avr
And notice how it says: "Use `configure --target=avr --enable-languages="c"' to
configure GCC." and how it refers too http://www.nongnu.org/avr/ for further
information, which almost directly links to:
http://www.nongnu.org/avr-libc/user-manual/install_tools.html

So I'm pretty sure (but not 100%) that this is correct. This is also how for
example cdk4avr, which I've been using under Linux until now, does it.
Comment 7 Ralf Corsepius 2007-05-02 11:34:59 EDT
(In reply to comment #6)
> Notice that the link above is THE install manual of THE libc for avr. Also avr
> has (rudimentary) C++ support, but no libstdc++ support.
Well, normally, g++ is tied to libstdc++ and is useless without libstdc++.

> Its libc also has no
> threading support etc. 
That's clear. Threads are part of the OS, so there is no way to support them
without OS.

> This is a microcontroller environment with as little as
> 512 bytes of total RAM (not Kbytes but bytes! including space for the stack).
I know.

> Thus most of the gcc features which require libc support simply do not apply.
Probably such as g++.

> Also see:
> http://gcc.gnu.org/install/specific.html#avr
> And notice how it says: "Use `configure --target=avr --enable-languages="c"'
This makes sense. AFAICT, c++ on the avr is not supported at all.

Anyway, a bug in your package:
./avr-g++ -v -c tmp.cc -o tmp.o
Using built-in specs.
Target: avr
Configured with: ../gcc-4.1.2/configure --prefix=/usr --enable-languages=c,c++
--target=avr --disable-nls --mandir=/usr/share/man --infodir=/usr/share/info
Thread model: single
gcc version 4.1.2
 /users/packman/src/rpms/SPECS/usr/bin/../libexec/gcc/avr/4.1.2/cc1plus -quiet
-v -iprefix /users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/ tmp.cc
-quiet -dumpbase tmp.cc -auxbase-strip tmp.o -version -fno-rtti
-fno-enforce-eh-specs -fno-exceptions -o /tmp/ccQf1d25.s
ignoring nonexistent directory
"/users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/../../../../include/c++/4.1.2"
ignoring nonexistent directory
"/users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/../../../../include/c++/4.1.2/avr"
ignoring nonexistent directory
"/users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/../../../../include/c++/4.1.2/backward"
ignoring nonexistent directory
"/users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/../../../../avr/sys-include"
ignoring nonexistent directory
"/users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/../../../../avr/include"
ignoring nonexistent directory "/usr/lib/gcc/../../include/c++/4.1.2"
ignoring nonexistent directory "/usr/lib/gcc/../../include/c++/4.1.2/avr"
ignoring nonexistent directory "/usr/lib/gcc/../../include/c++/4.1.2/backward"
ignoring nonexistent directory "/usr/lib/gcc/avr/4.1.2/include"
ignoring nonexistent directory "/usr/lib/gcc/../../avr/sys-include"
ignoring nonexistent directory "/usr/lib/gcc/../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /users/packman/src/rpms/SPECS/usr/bin/../lib/gcc/avr/4.1.2/include
End of search list.
GNU C++ version 4.1.2 (avr)
        compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-51).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64013
Compiler executable checksum: b37c1702f0f613ffe6c2ea8cd679740a
 /usr/lib/gcc/../../avr/bin/as -o tmp.o /tmp/ccQf1d25.s


Note the c++ header search paths! These refer to the host's libstdc++'s headers,
not the target ones.

You want to use 
%configure --enable-version-specific-runtime-libs

This will cause gcc to search for libstdc++ only on its internal search paths.

Comment 8 Hans de Goede 2007-05-02 14:37:44 EDT
(In reply to comment #7)
> > Thus most of the gcc features which require libc support simply do not apply.
> Probably such as g++.
> 

I tend to agree with you, but the avr-gcc developers have actually made it
possible to write c++ code (with exceptions) even on the avr. Why? i don't know,
but I do know some people are actually using this (some colleagues actually). So
lets keep this in, but indeed put it in a sub-package
 
> Note the c++ header search paths! These refer to the host's libstdc++'s headers,
> not the target ones.
> 
> You want to use 
> %configure --enable-version-specific-runtime-libs
> 

Will do / add.

(In reply to comment #5)
> Building exposes one of my "very friends" of bugs in rpm:
> ...
> /usr/bin/strip: Unable to recognise the format of the input file
> ...
> 
> To work around this issue I am rewriting %__os_install_post.
> (Details to be found in my rtems*gcc*specs.).
> 

This is the same as done in the sdcc spec, right? Then I'll try to add this
"fix" to the avr-gcc specfile.
Comment 9 Ralf Corsepius 2007-05-03 05:07:08 EDT
(In reply to comment #8)
> (In reply to comment #7)

> I tend to agree with you, but the avr-gcc developers have actually made it
> possible to write c++ code (with exceptions)
Well, I would have to investigate in depth, but I am having really strong doubts
on this - For avr-rtems, we disable c++.

> > /usr/bin/strip: Unable to recognise the format of the input file
> > ...
> > 
> > To work around this issue I am rewriting %__os_install_post.
> > (Details to be found in my rtems*gcc*specs.).
> > 
> 
> This is the same as done in the sdcc spec, right?
Yep, the variant in sdcc is a stripped down version of what I use for rtems.
Comment 10 Hans de Goede 2007-05-14 11:12:31 EDT
New version:

* Mon May 14 2007 Hans de Goede <j.w.r.degoede@hhs.nl> 4.1.2-3
- Use normal make / make install instead off make all-gcc / make install-gcc
- Add --disable-libssp to the configure flags, freebsd ports, the avrlibc docs,
  and debian package all do this, and ./configure does not do this automaticly
- Add --enable-version-specific-runtime-libs, as we don't want gcc/g++ to be
  looking in the default include/lib paths
- Add --with-system-zlib and zlib-devel BR
- Add 2 usefull patches from freebsd ports collection
- Split g++ off into a seperate package
- Add special script/workaround to avoid debuginfo generation for non native
  libs

Get it here:
Spec URL: http://people.atrpms.net/~hdegoede/avr-gcc.spec
SRPM URL: http://people.atrpms.net/~hdegoede/avr-gcc-4.1.2-3.fc7.src.rpm
Comment 11 Ralf Corsepius 2007-05-20 01:50:43 EDT
MUSTFIX: 
* package doesn't honour RPM_OPT_FLAGS

Override CC at configuration time to achieve this:
CC="%{__cc} ${RPM_OPT_FLAGS}" \
... configure ...

* You are patching GCC, i.e. shipping a modified GCC.
It's GCC convention to alter the id strings (c.f. gcc -v) to denote that your
GCC is not the FSF's GCC.
c.f. gcc/version.c

[In my packages, I am changing VERSUFFIX]

CONSIDER:
* You are using monolytic gcc tarball. Using the gcc-core and gcc-g++ tarballs
instead cuts down the size of *.src.rpm and diskspace required to build by
several GBs.

* You are applying patches to GCC. This can kills critical timestamps.
To be on the safe side, you should run contrib/gcc_update inside of the expanded
GCC source tree.

* smp-flags. In general, building GCC is not smp-safe. However, you are only
building a subset from GCC which is likely not to suffer from such issues, so 
this might not hit or apply to this package.

* Check and consider to remove
/usr/lib/gcc/avr/4.1.2/install-tools
/usr/libexec/gcc/avr/4.1.2/install-tools
Normally, these are not useful for embedded cross-compilers.
Comment 12 Hans de Goede 2007-05-20 11:00:35 EDT
Created attachment 155061 [details]
improved specfile

New version with all items from comment #11 fixed.

Go get it here:
Spec URL: http://people.atrpms.net/~hdegoede/avr-gcc.spec
SRPM URL: http://people.atrpms.net/~hdegoede/avr-gcc-4.1.2-4.fc8.src.rpm

Erm, or that is were it should be but atrpms seems down, attaching the new spec
instead.

Ralf your thorough and professional input is much appreciated!
Comment 13 Ralf Corsepius 2007-05-21 04:09:10 EDT
I would have continued the review, but ATM, 
http://people.atrpms.net/~hdegoede seems to be inaccessible.
Comment 14 Hans de Goede 2007-05-21 04:55:29 EDT
(In reply to comment #13)
> I would have continued the review, but ATM, 
> http://people.atrpms.net/~hdegoede seems to be inaccessible.

I know :( I hope Axel will fix this soon.

Thats why I attached the specfile, the sources can be get with spectool -g, and
the patches are unchanged from the previous SRPM (if you still have that)
Comment 15 Hans de Goede 2007-05-21 18:43:58 EDT
Atrpms is back, so you can get the latest version here, as promised earlier:
Spec URL: http://people.atrpms.net/~hdegoede/avr-gcc.spec
SRPM URL: http://people.atrpms.net/~hdegoede/avr-gcc-4.1.2-4.fc8.src.rpm
Comment 16 Ralf Corsepius 2007-05-22 04:37:16 EDT
*-4 looks good.

APPROVED.
Comment 17 Hans de Goede 2007-05-22 08:53:20 EDT
New Package CVS Request
=======================
Package Name:      avr-gcc
Short Description: Cross Compiling GNU GCC targeted at avr
Owners:            j.w.r.degoede@hhs.nl
Branches:          FC-6 F-7 devel
InitialCC:         <empty>
Comment 18 Hans de Goede 2007-05-22 08:54:03 EDT
Oops forgot fedora-cvs flag, cvs-admins see comment above.
Comment 19 Tom "spot" Callaway 2007-05-22 09:26:21 EDT
Cvs done.
Comment 20 Hans de Goede 2007-05-23 10:41:48 EDT
Many thanks to Ralf for the review!

Imported and build, closing.
Comment 21 Hans de Goede 2007-05-23 10:42:43 EDT
p.s.

Changing assignee to ralf for proper bookkeeping of who did which reviews.
Comment 22 Thibault North 2010-07-11 11:59:19 EDT
Package Change Request
======================
Package Name: avr-gcc
New Branches: EL-6
Owners: tnorth trondd

We would like to have FEL-related packages available for EL-6. Thanks !
Comment 23 Kevin Fenzi 2010-07-12 13:08:51 EDT
CVS done (by process-cvs-requests.py).

Note You need to log in before you can comment on or make changes to this bug.