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.
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".
(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.
Note to self, add this patch for support of latest avr's: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/avr-gcc/files/patch-newdevices?rev=1.16;content-type=text%2Fplain And maybe other patches from: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/devel/avr-gcc/files/
(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
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.).
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.
(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.
(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.
(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.
New version: * Mon May 14 2007 Hans de Goede <j.w.r.degoede> 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
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.
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!
I would have continued the review, but ATM, http://people.atrpms.net/~hdegoede seems to be inaccessible.
(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)
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
*-4 looks good. APPROVED.
New Package CVS Request ======================= Package Name: avr-gcc Short Description: Cross Compiling GNU GCC targeted at avr Owners: j.w.r.degoede Branches: FC-6 F-7 devel InitialCC: <empty>
Oops forgot fedora-cvs flag, cvs-admins see comment above.
Cvs done.
Many thanks to Ralf for the review! Imported and build, closing.
p.s. Changing assignee to ralf for proper bookkeeping of who did which reviews.
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 !
CVS done (by process-cvs-requests.py).