Bug 242206 - Review Request: arm-gp2x-linux-gcc - Cross Compiling GNU GCC targeted at arm-gp2x-linux
Review Request: arm-gp2x-linux-gcc - Cross Compiling GNU GCC targeted at arm-...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Kofler
Fedora Package Reviews List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-02 03:12 EDT by Hans de Goede
Modified: 2010-09-06 19:43 EDT (History)
0 users

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


Attachments (Terms of Use)
The promised gcc-4.1.2-gcc_eh.patch (patches gcc-c++, so only for non-bootstrap GCC) (808 bytes, patch)
2007-08-03 09:07 EDT, Kevin Kofler
no flags Details | Diff
The specfile patch for gcc-4.1.2-gcc_eh.patch (1.61 KB, patch)
2007-08-03 09:09 EDT, Kevin Kofler
no flags Details | Diff

  None (edit)
Description Hans de Goede 2007-06-02 03:12:49 EDT
Spec URL: http://people.atrpms.net/~hdegoede/arm-gp2x-linux-gcc.spec
SRPM URL: http://people.atrpms.net/~hdegoede/arm-gp2x-linux-gcc-4.1.2-5.fc8.src.rpm
Description:
This is a Cross Compiling version of GNU GCC, which can be used to
compile programs for the arm-gp2x-linux platform, instead of for the
native %{_arch} platform.

This packages requires (which are still under review):
arm-gp2x-linux-binutils - bug 234749
arm-gp2x-linux-kernel-headers - bug 242203
Comment 1 Kevin Kofler 2007-07-26 15:40:40 EDT
Reviewing this one.
Comment 2 Kevin Kofler 2007-07-26 16:08:33 EDT
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.)
Comment 3 Hans de Goede 2007-07-26 16:58:51 EDT
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.

Comment 4 Kevin Kofler 2007-07-26 17:07:09 EDT
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.
Comment 5 Kevin Kofler 2007-07-28 11:01:37 EDT
Is " (Fedora %{version}-%{release})" really the right VERSUFFIX to use here? 
This GCC is very different from the native Fedora GCC.
Comment 6 Hans de Goede 2007-07-28 12:19:01 EDT
(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?
Comment 7 Kevin Kofler 2007-07-28 12:20:07 EDT
Not for now, but I haven't run it through the long review checklist yet.
Comment 8 Hans de Goede 2007-07-28 12:22:18 EDT
(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.
Comment 9 Kevin Kofler 2007-07-28 13:06:19 EDT
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.)
Comment 10 Kevin Kofler 2007-07-28 13:26:16 EDT
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. ;-)
Comment 11 Kevin Kofler 2007-07-28 13:35:28 EDT
(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
Comment 12 Hans de Goede 2007-07-28 13:57:14 EDT
(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!
Comment 13 Hans de Goede 2007-07-28 13:58:08 EDT
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@hhs.nl
Branches:          FC-6 F-7 devel
InitialCC:         <empty>


Comment 14 Jason Tibbitts 2007-07-28 16:34:55 EDT
CVS done.
Comment 15 Hans de Goede 2007-07-29 02:40:19 EDT
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.
Comment 16 Kevin Kofler 2007-07-30 19:08:36 EDT
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.
Comment 17 Hans de Goede 2007-08-02 14:06:20 EDT
(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.
Comment 18 Kevin Kofler 2007-08-02 14:08:24 EDT
But this one is ARM, not AVR.
Comment 19 Hans de Goede 2007-08-02 14:09:20 EDT
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?
Comment 20 Kevin Kofler 2007-08-02 14:13:42 EDT
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.)
Comment 21 Hans de Goede 2007-08-02 14:22:03 EDT
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.
Comment 22 Kevin Kofler 2007-08-02 14:29:19 EDT
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.
Comment 23 Kevin Kofler 2007-08-02 14:31:15 EDT
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.
Comment 24 Hans de Goede 2007-08-02 16:53:05 EDT
(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!

Comment 25 Kevin Kofler 2007-08-02 17:34:34 EDT
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.
Comment 26 Kevin Kofler 2007-08-03 09:07:23 EDT
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).
Comment 27 Kevin Kofler 2007-08-03 09:09:07 EDT
Created attachment 160609 [details]
The specfile patch for gcc-4.1.2-gcc_eh.patch
Comment 28 Kevin Kofler 2007-08-03 09:10:26 EDT
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.
Comment 29 Hans de Goede 2007-08-03 14:13:53 EDT
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.
Comment 30 Hans de Goede 2007-08-05 16:35:47 EDT
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.
Comment 31 Hans de Goede 2010-09-06 04:47:10 EDT
Package Change Request
======================
Package Name: arm-gp2x-linux-gcc
New Branches: el6
Owners: jwrdegoede
Comment 32 Kevin Fenzi 2010-09-06 19:43:20 EDT
Git done (by process-git-requests).

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