Reviewing this one.

The bootstrap hack is fun. :-) Have you tried -Dinhibit_libc? If that doesn't 
work, then I guess your solution is the best we can do.

(TIGCC has its own fun way to deal with this problem: we simply have our own 
implementation of all the libgcc routines we need in our C library (TIGCCLIB) 
and my compiling scripts simply run the GCC compilation up to the first error 
(somewhere in libgcc). ;-) But this won't work for a standard target which does 
need libgcc.)

gcc for Linux with glibc may not be compiled with inhibit_libc, so this is the
only way to go. The really big problem was:
- getting this to build inside a dir, without it trying to install headers to
  the filesystem during the build
- then install inside a buildroot
- and then run without wanting to find some of its file inside the buildroot 
  instead of there regular patches.

After many days of messing around I found mandrake's patch which makes it
possible to use --with-build-sysroot, without also using --with-sysroot, fixing
the puzzle.

Sounds good, thanks for the explanation.

Another thing I noticed:
> # In general, building GCC is not smp-safe
> make
FYI, they are at least trying to use "serialization dependencies" and similar 
hacks to make it work. But I don't know whether it actually works, I never use 
parallel make. So assuming it doesn't is probably safest anyway.

The good news is that I don't see anything fundamentally bad with your 
packages, so I'm going to run these through the regular checklist (of course 
taking into account that these are cross-compiling packages, so they'll get 
away with things like using /usr/%{target} which other packages wouldn't ;-) ) 
next.

Is " (Fedora %{version}-%{release})" really the right VERSUFFIX to use here? 
This GCC is very different from the native Fedora GCC.

(In reply to comment #5)
> Is " (Fedora %{version}-%{release})" really the right VERSUFFIX to use here? 
> This GCC is very different from the native Fedora GCC.

I don't know, maybe " (Fedora GP2X %{version}-%{release})" or " (GP2X
%{version}-%{release})", I think I like " (Fedora GP2X %{version}-%{release})"
the best.

Before I roll a new release, do you see any other issues?

Not for now, but I haven't run it through the long review checklist yet.

(In reply to comment #7)
> Not for now, but I haven't run it through the long review checklist yet.

I'll wait for that then.

rpmlint complains about these:
E: arm-gp2x-linux-gcc hardcoded-library-path in 
$RPM_BUILD_ROOT/usr/lib/libiberty.a
E: arm-gp2x-linux-gcc hardcoded-library-path in 
$RPM_BUILD_ROOT/usr/lib/gcc/%{target}/%{version}/install-tools
E: arm-gp2x-linux-gcc hardcoded-library-path in 
$RPM_BUILD_ROOT/usr/lib/gcc/%{target}/%{version}/*.la
E: arm-gp2x-linux-gcc hardcoded-library-path in %{_prefix}/lib/gcc/%{target}/
E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/lib*c++.a
E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/include/c++
E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/lib*c++.a
E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/include/c++

Shouldn't these be using %{_libdir}? (My computer is i386, so I can't really 
test this.)

Looking at what these files actually are, they are all target files, 
so /usr/lib is OK in principle. But if you can test on an x86_64 machine to 
make sure the files really do end up in /usr/lib when building for x86_64, this 
would be useful. Otherwise, I guess we'll see with the first Koji build. ;-)

(NOTE: The parts where a binary RPM is needed were checked against the 
bootstrap version.)

MUST Items:
+ rpmlint output:
  + SPRM has this:
    W: arm-gp2x-linux-gcc rpm-buildroot-usage %prep sed -e 's,find 
$RPM_BUILD_ROOT,find $RPM_BUILD_ROOT%_bindir $RPM_BUILD_ROOT%_libexecdir,' $a > 
$b
    This one is OK.
    E: arm-gp2x-linux-gcc hardcoded-library-path in 
$RPM_BUILD_ROOT/usr/lib/libiberty.a
    E: arm-gp2x-linux-gcc hardcoded-library-path in 
$RPM_BUILD_ROOT/usr/lib/gcc/%{target}/%{version}/install-tools
    E: arm-gp2x-linux-gcc hardcoded-library-path in 
$RPM_BUILD_ROOT/usr/lib/gcc/%{target}/%{version}/*.la
    E: arm-gp2x-linux-gcc hardcoded-library-path 
in %{_prefix}/lib/gcc/%{target}/
    E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/lib*c++.a
    E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/include/c++
    E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/lib*c++.a
    E: arm-gp2x-linux-gcc hardcoded-library-path 
in /usr/lib/gcc/%{target}/%{version}/include/c++
    (see comment #9 and comment #10). These are OK in principle, assuming the 
files actually do end up in /usr/lib even on x86_64. It's OK for them to be 
there because they're target files.
  + main package has this:
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/stdarg.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/stddef.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/varargs.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/linux/a.out.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/mmintrin.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/libgcc_eh.a
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/libgcov.a
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/syslimits.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/stdbool.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/float.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/unwind.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/libgcc.a
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/iso646.h
    W: arm-gp2x-linux-gcc 
devel-file-in-non-devel-package /usr/lib/gcc/arm-gp2x-linux/4.1.2/include/limits.h
    These are all OK, as this is a developer package.
  + -debuginfo has empty output.
+ named and versioned according to the Package Naming Guidelines
+ spec file name matches base package name
+ Packaging Guidelines:
  + License GPL OK, matches actual license
  + No known patent problems
  + No emulator, no firmware, no binary-only or prebuilt components
  + Complies with the FHS
  + proper changelog, tags, BuildRoot, Requires, BuildRequires, Summary, 
Description
  + no non-UTF-8 characters
  + relevant documentation is included
  + RPM_OPT_FLAGS are used
  + debuginfo package is valid
  + no host static libraries nor .la files
    (I think we can give the target static libraries (libgcc.a, libgcc_eh.a and 
libgcov.a) a pass.)
  + no duplicated system libraries
    (libiberty is always static, so it can't be shared with the native version)
  + no rpaths, at least on i386 (I ran readelf -d on the executables)
  + no configuration files, so %config guideline doesn't apply
  + no init scripts, so init script guideline doesn't apply
  + no GUI programs, so no .desktop file present or needed
  + no timestamp-clobbering file commands
  + omission of _smp_mflags justified by a comment
  + scriptlets are valid
  + not a web application, so web application guideline doesn't apply
  + no conflicts
+ complies with all the legal guidelines
+ COPYING included as %doc
+ spec file written in American English
  (nitpick: s/usefull/useful/)
+ spec file is legible
+ source matches upstream:
  MD5SUM: 2af3fb599635219171c6ae1f3034888a
  SHA1SUM: d6875295f6df1bec4a6f4ab8f0da54bfb8d97306
  glibc-2.3.6.tar.bz2:
  MD5SUM: bfdce99f82d6dbcb64b7f11c05d6bc96
  SHA1SUM: 82d0487419f1bdbf2dee439c344e89d6af47e558
  glibc-linuxthreads-2.3.6.tar.bz2:
  MD5SUM: d4eeda37472666a15cc1f407e9c987a9
  SHA1SUM: 10190168bf948556afdfff46f87f9208402d810f
+ builds on at least one arch (F7 i386 live system)
+ no known non-working arches, so no ExcludeArch needed
+ no missing BR
+ translations are disabled (because they'd conflict with the native versions), 
so translation/locale guidelines don't apply
+ no shared libraries, so no ldconfig calls needed
+ package not relocatable
+ ownership correct (owns package-specific directories, doesn't own directories 
owned by another package)
+ no duplicate files in %files
+ permissions set properly (%defattr present)
+ %clean section present and correct
+ macros used where possible (%configure not used for several reasons, 
including it playing jokes with --target and upstream recommending building 
outside the source directory)
+ no non-code content
+ no large documentation files, so no -doc package needed
+ %doc files not required at runtime
+ no host headers, target headers are OK in this cross-development package
+ no host static libraries, so no -static package needed
+ no .pc files, so no Requires: pkgconfig needed
+ no shared libraries, so .so symlink guidelines don't apply
+ no -devel package, so the guideline to require the main package in it doesn't 
apply
+ no .la files
+ no GUI programs, so no .desktop file needed
+ buildroot is deleted at the beginning of %install
  (same nitpick about mkdir $RPM_BUILD_ROOT as for arm-gp2x-linux-binutils)
+ all filenames are valid UTF-8

SHOULD Items:
+ license already included upstream
+ no translations for description and summary provided by upstream
* Skipping mock test.
* Skipping the "all architectures" test, I only have i386.
+ package functions as described:
  I can at least compile this:
  int main(void)
  {
    return 0;
  }
  up to an .o file with the bootstrap compiler. It doesn't link because there's 
no crt1.o without glibc.
+ scriptlets are sane
+ no subpackages other than -devel, so "Usually, subpackages other than devel 
should require the base package using a fully versioned dependency." is 
irrelevant
+ no .pc files, so "placement of .pc files" is irrelevant
+ no file dependencies

APPROVED

(In reply to comment #10)
> Looking at what these files actually are, they are all target files, 
> so /usr/lib is OK in principle. But if you can test on an x86_64 machine to 
> make sure the files really do end up in /usr/lib when building for x86_64, this 
> would be useful. Otherwise, I guess we'll see with the first Koji build. ;-)

gcc always puts its files under /usr/lib even on a mutlilib system, becasue the
multilib gcc can build binaries for both libs.

I have an x86_64 as my main workstation, and Fedora's x86_64 gcc has its files
under /usr/lib, so this is really 100% normal.

(In reply to comment #11)
> 
> APPROVED

Thanks, I really appreciate these reviews!

New Package CVS Request
=======================
Package Name:      arm-gp2x-linux-gcc
Short Description: Cross Compiling GNU GCC targeted at arm-gp2x-linux
Owners:            j.w.r.degoede
Branches:          FC-6 F-7 devel
InitialCC:         <empty>

CVS done.

Imported and build, I'm leaving the bug open until glibc is there, so that I can
build it with "%define boostrap 0"

I forgot to change the VERSUFFIX, I'll do that in the non bootstrapped build.

I built glibc now and built a non-bootstrap GCC against it. C works, but C++ 
chokes on this simple program:
#include <iostream>

int main(void)
{
  std::cout << "Hello World!" << std::endl;
  return 0;
}

This compiles fine with the native g++, but arm-gp2x-linux-g++ gives me tons of 
undefined references to `_Unwind_SjLj_Register', `_Unwind_SjLj_Unregister' 
and`_Unwind_SjLj_Resume'. -fno-exceptions doesn't help.

(In reply to comment #16)
> I built glibc now and built a non-bootstrap GCC against it. C works, but C++ 
> chokes on this simple program:
> #include <iostream>
> 
> int main(void)
> {
>   std::cout << "Hello World!" << std::endl;
>   return 0;
> }
> 
> This compiles fine with the native g++, but arm-gp2x-linux-g++ gives me tons of 
> undefined references to `_Unwind_SjLj_Register', `_Unwind_SjLj_Unregister' 
> and`_Unwind_SjLj_Resume'. -fno-exceptions doesn't help.


Thats to be expected, the C++ implementation of avr comes without libstdc++, it
offers constructs like class, and inheritance, but no c++ library.

Which still make it usefull, I know people acutally using it and its shipped
with other popular versions of avr-gcc such as winavr too.

But this one is ARM, not AVR.

Erm, scrap that ( /me stupid ) that is not to be expected as this is not avr-gcc
 (which you just added and I mid-air colided with, that was fast), still this
feels familiar, can you try with -lstdc++ added to the cmdline?

This looks like a linking order problem. If I use either -lsupc++ or -lgcc_eh, 
I get the same undefined references, but if I add -lsupc++ -lgcc_eh it links. 
(-lstdc++ doesn't help.)

Now I remember I saw this too, but when building statically, so I contributed it
to the static linking as that is known to cause problems like this. Do you have
any clues?

Anyways I'll do a clean rebuild of my toolchain over here to be sure we are
working from the same base and see if I can fix it, still any clues are
appreciated as this is uncharted territory for me.

g++ -v clarifies some things: If I only pass -lgcc_eh, I get -lgcc_eh -lstdc++ 
as the linking order. This doesn't work because libgcc_eh is static, so it 
needs to come after the shared objects. (If I don't pass it at all, it's 
missing entirely, which is again wrong for static libraries.) If I 
pass -lsupc++ -lgcc_eh, I get -lsupc++ -lgcc_eh -lstdc++ and this is enough to 
draw the symbols in. Passing -lstdc++ -lgcc_eh also works.

The proper fix should be to add -lgcc_eh to the g++ specs.

Replying to your latest comment: indeed, the root cause of this issue is that 
libgcc_eh is static only. If there's a shared libgcc_eh on the GP2X (hopefully 
a compatible one), it makes sense to use one in the cross-compiler, otherwise 
adding -lgcc_eh to the specs is the way to go.

(In reply to comment #22)

I doubt gcc_eh is in the firmware and I'm sure it won't be compatible, so ...

> 
> The proper fix should be to add -lgcc_eh to the g++ specs.

I assume you mean something in gcc called "specs" and not the specfile, can you
give me a little pointer to where exactly I should do this, (which file to patch
/ configure option to use). If you don't know I'll dig into this myself, but if
you do know that would be great!

Yes, GCC has something called "specs" where default options passed by gcc to 
the tools it invokes are stored. I'll write a patch for you (should be one 
line) ASAP.

Created attachment 160608 [details]
The promised gcc-4.1.2-gcc_eh.patch (patches gcc-c++, so only for non-bootstrap GCC)

It turns out the C++ specs are actually hardcoded in gcc/cp/g++-spec.c, not
stored as text. There's a LIBSTDCXX macro which the target can redefine, but
it's assumed to always be a single argument. So I had to patch the code itself
to add the -lgcc_eh.

I tested it to work. I'm also attaching a specfile patch with this patch
applied and some minor cleanups (VERSUFFIX, License tag).

Created attachment 160609 [details]
The specfile patch for gcc-4.1.2-gcc_eh.patch

I should clarify the "tested" part: I've tested that it makes the C++ "Hello 
World" link, but I don't have a GP2X, so I can't test whether it actually runs.

Thanks a lot for both patches! I've applied both as is and I'm now chain
building arm-gp2x-glibc, followed by a non bootstrap gcc using your patch and
specfile.

About the testing I have compiled and run some serious c++ programs, working
around the -lgcc_eh bug by just adding it at the end of the link cmd myself.

For some unknown reason the first glibc build didn't produce an rpm (although it
succeeded according to koji).

Doing a second build has fixed this, and a new non bootstrap gcc with c++ and
your patch has been build now. ONce more, many thanks for all your input.

Package Change Request
======================
Package Name: arm-gp2x-linux-gcc
New Branches: el6
Owners: jwrdegoede

Git done (by process-git-requests).