Note this package is identical to the avr-binutils package except for the
%define target. For avr-binutils review see: bug 234750

Shouldn't this be based on the Fedora binutils package, but with the suitable
target definition? I did specfiles based on Fedora's for cross-compilation (to
i686) once upon a time.

Fedora's binutils spec is IMHO somewhat ugly/messy. If it turns out that this
will become just as ugly/messy I might go that way. But for now I prefer to
start clean.

Also this is not for arm-linux-fedora, but for arm-linux, the first target I
have in mind is my gp2x handheld game device. But I'm trying to make this more
generic then that.

(In reply to comment #4)
> Also this is not for arm-linux-fedora, 
This would be arm-redhat-linux. 

> but for arm-linux, 
arm-linux is not useful, because there exist many flavors of "*-linux"
toolchains and each vendor/distributor ships it's own variant of toolchains.

> the first target I
> have in mind is my gp2x handheld game device. But I'm trying to make this more
> generic then that.
This won't work.

(In reply to comment #5)
> (In reply to comment #4)
> > Also this is not for arm-linux-fedora, 
> This would be arm-redhat-linux. 
> 
> > but for arm-linux, 
> arm-linux is not useful, because there exist many flavors of "*-linux"
> toolchains and each vendor/distributor ships it's own variant of toolchains.
> 
> > the first target I
> > have in mind is my gp2x handheld game device. But I'm trying to make this more
> > generic then that.
> This won't work.
> 

Hmm, I thought that with gcc-multilib, it should be possible to have 2 generic
toolchains: arm-linux and arm-uclinux, so that atleast the toolchain could be
shared. But I guess when you add things like g++ ABI, that then even that is not
possible. So does this mean that it would be better to just do an
arm-gp2x-linux toolchain then? That would actually make things quite a bit easier.

After much study of this I have come to the conclusion, that it indeed is a bad
idea to try an make a generic toolchain. So now we've been working on a toochain
specific for the gp2x handheld console (arm linux glibc inside) as that is what
I have and want to develop for.

Here is a new version of arm-gp2x-linux-binutils for review:
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-binutils.spec
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-binutils-2.17-1.fc8.src.rpm

Hans, could you elaborate this change:

* Thu May 24 2007 Hans de Goede <j.w.r.degoede> 2.17-1
- Revert to GNU 2.17 release as using GNU releases are better for non linux
  targets

You revert to using the FSF sources, nevertheless you call this target "*-linux"?

What kind of target is this? Which libc is going to be used?

(In reply to comment #8)
> Hans, could you elaborate this change:
> 
> * Thu May 24 2007 Hans de Goede <j.w.r.degoede> 2.17-1
> - Revert to GNU 2.17 release as using GNU releases are better for non linux
>   targets
> 
> You revert to using the FSF sources, nevertheless you call this target "*-linux"?
> 

Yes, my bad, thats a copy and paste error from the avr-binutils spec. After much
experimenting and researching what others did, I ended up using FSF
binutils-2.16.1 as that is what all other available preconfigured toolchains for
this target use. However 2.16 has a bug which causes ar and ranlib to fail when
compiled with -DFORTIFY_SOURCE=2, which is fixed in binutils 2.17 . Since the
other available toolchains use FSF binutils and since 2.16 was giving me some
problems, I decided to go to FSF 2.17 

> What kind of target is this? Which libc is going to be used?
The gp2x is a handheld game console, with an arm processor and Linux inside. The
Linux inside uses glibc. See:
http://wiki.gp2x.org/wiki/Main_Page
http://www.gp2x.com/

I've found 2 working preconfigured toolchains for this:

* http://open2x.org

Uses:
gcc-4.1.1
binutils-2.16.1
glibc-2.3.5 + linuxthreads

I'm modeling my current Fedora attempts after their work, I'm using:
gcc-4.1.2
binutils-2.17
glibc-2.3.6 + linuxthreads

* gp2xdev-20060525.tar.bz2

Which can be downloaded here (60 Mb!!):
http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,14,1609

This is a huge tarball with pre-patched sources, just type make to get things
going. I've been doing diffs against pristine upstream sources to see what they
have patched. They are mostly using the same patches as open2x. Since open2x
distributes the patches seperately, and in general since open2x is an alive
project unlike this, I've decided to base my Fedora attempts on the open2x stuff.

(In reply to comment #9)
> (In reply to comment #8)
> > Hans, could you elaborate this change:
> > 
> > * Thu May 24 2007 Hans de Goede <j.w.r.degoede> 2.17-1
> > - Revert to GNU 2.17 release as using GNU releases are better for non linux
> >   targets
> > 
> > You revert to using the FSF sources, nevertheless you call this target
"*-linux"?
> > 
> 
> Yes, my bad, thats a copy and paste error from the avr-binutils spec. After much
> experimenting and researching what others did, I ended up using FSF
> binutils-2.16.1 as that is what all other available preconfigured toolchains for
> this target use. However 2.16 has a bug which causes ar and ranlib to fail when
> compiled with -DFORTIFY_SOURCE=2, which is fixed in binutils 2.17 .
I know :) 

I had a patch for my rtems binutils packages when binutils-2.16 was current.
Jakub had a different one.

> Since the
> other available toolchains use FSF binutils and since 2.16 was giving me some
> problems, I decided to go to FSF 2.17 
OK with me. There is nothing wrong with using FSF source on linux targets, I
just wanted to know, because diverging from "nominal upstream" can cause nasty
incompatiblities. 

(Note: binutils-2.16 and binutils-2.17 aren't necessarily compatible).

> * http://open2x.org

> I'm modeling my current Fedora attempts after their work, I'm using:
> gcc-4.1.2
> binutils-2.17
> glibc-2.3.6 + linuxthreads
OK, that's what I wanted to know. It means naming the target *-linux is legitimated.

(In reply to comment #10)
> (Note: binutils-2.16 and binutils-2.17 aren't necessarily compatible).
> 

Well sofar I haven't seen any problems (but we're not very far yet). What do you
advice, knowing that others who have build a toolchain for the gp2x all use
2.16.1 ???

Also could you take a quick look at our gcc-stage1 spec, and tell if we are
atleast going in the right direction? Notice that this is a use once throw away
spec, to get an arm-gp2x-linux-gcc in the buildsys to build
arm-gp2x-linux-glibc, once the glibc is there a real/normal gcc spec will be
used to build the "final" gcc (I'm planning on renaming the stage1 spec and keep
it in CVS for future reference).

The spec is here:
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-gcc.spec
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-gcc-4.1.2-1.fc8.src.rpm

Thanks!

Ah well, so it turns out that glibc-2.3.x doesn't compile with binutils 2.17, so
back to 2.16.1 it is:
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-binutils.spec
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-binutils-2.16.1-1.fc8.src.rpm

MUSTFIX:

* package doesn't acknowledge RPM_OPT_FLAGS:
...
CFLAGS=`echo $RPM_OPT_FLAGS|sed s/-D_FORTIFY_SOURCE=2/-D_FORTIFY_SOURCE=1/` 
...

cf. the patch to bfd/archive.c in
http://www.rtems.com/cgi-bin/viewcvs.cgi/rtems/contrib/crossrpms/patches/binutils-2.16.1-rtems-20050708.diff?rev=1.1.2.2

This is the patch I apply to work-around the memory leak in binutils-2.16.1. 
I don't know if your target might be suffering from more.

(In reply to comment #13)
> MUSTFIX:
> 
> * package doesn't acknowledge RPM_OPT_FLAGS:
> ...
> CFLAGS=`echo $RPM_OPT_FLAGS|sed s/-D_FORTIFY_SOURCE=2/-D_FORTIFY_SOURCE=1/` 
> ...
> 
> cf. the patch to bfd/archive.c in
>
http://www.rtems.com/cgi-bin/viewcvs.cgi/rtems/contrib/crossrpms/patches/binutils-2.16.1-rtems-20050708.diff?rev=1.1.2.2
> 
> This is the patch I apply to work-around the memory leak in binutils-2.16.1. 
> I don't know if your target might be suffering from more.

That patch should indeed fix the backtraces I've seen sofar. I'll do a new
version with it and then rebuild the entire toolchain to be sure it works.

I'll get back to you with the results once the full rebuild is done.

The whole toolchain still builds fine with the patch and without the
fortify-source hack.

Here is a new version with the patch and without the hack:
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-binutils.spec
http://people.atrpms.net/~hdegoede/arm-gp2x-linux-binutils-2.16.1-2.fc8.src.rpm

Reviewing this one.

So first of all, using FSF Binutils for a Linux/glibc target is not a problem. 
The "Linux Binutils" H.J.Lu releases are actually snapshots from FSF CVS (this 
is why they usually have 2.x.90 numbering) with some patches applied, and only 
tested for Linux targets. FSF releases go through an actual release process, 
they aren't snapshotted straight out of CVS like the "Linux Binutils". This has 
both advantages (more testing, less regressions) and disadvantages (not always 
the latest bugfixes). If FSF Binutils is what all the other SDKs for this 
targets use, it is the right choice here.

(In reply to comment #17)
> So first of all, using FSF Binutils for a Linux/glibc target is not a problem. 
> The "Linux Binutils" H.J.Lu releases are actually snapshots from FSF CVS (this 
> is why they usually have 2.x.90 numbering) with some patches applied, and only 
> tested for Linux targets. FSF releases go through an actual release process, 
> they aren't snapshotted straight out of CVS like the "Linux Binutils". This has 
> both advantages (more testing, less regressions) and disadvantages (not always 
> the latest bugfixes). If FSF Binutils is what all the other SDKs for this 
> targets use, it is the right choice here.

Yes, fsf binutils is what the other sdk's use, including open2x's sdk, which is
the closest thing to upstream the arm-gp2x-linux packages have, see:
http://open2x.org/open2x/index.html

So I definetively want to stick with fsf binutils 2.16.1

FSF binutils being more tested and less regressions is just an illusion, as I
see it the fact is that they have fewer testers and already by the time they are
released they are helplessly outdated.  Especially 2.16.1 binutils are more than
2 years old codebase, has many severe known bugs and isn't really supported
upstream anymore.

Hans already explained the reason for using 2.16.1:
> Ah well, so it turns out that glibc-2.3.x doesn't compile with binutils 2.17,
> so back to 2.16.1 it is

And from the arm-gp2x-linux-gcc changelog:
> - Glibc-2.3.5 is used because the arm is not supported in version 2.5

(In reply to comment #20)
> And from the arm-gp2x-linux-gcc changelog:
> > - Glibc-2.3.5 is used because the arm is not supported in version 2.5

I'm afraid that is an erroneous changelog entry the arm is supported in glibc-25
through the ports addon. The main reason for staying with glibc-2.3.5 and
binutils 2.16.1 is because this is what all the gp2x sdk's use.
 

More importantly, if the device is running 2.3.5, it doesn't make sense to use 
anything higher in the cross toolchain because programs dynamically linked 
against e.g. 2.5 won't run on 2.3.5.

So IMHO your choice of versions makes perfect sense.

+ rpmlint output OK:
  + SRPM and -debuginfo have empty output.
  + main package has this:
    W: arm-gp2x-linux-binutils non-standard-dir-in-usr arm-gp2x-linux
    which is OK for a cross-toolchain package
+ 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 (with the cross-toolchain exception 
for %{_prefix}/%{target})
  + proper changelog, tags, BuildRoot, Requires (none needed), BuildRequires 
(likewise), Summary, Description
  + no non-UTF-8 characters
  + relevant documentation is included
  + RPM_OPT_FLAGS are used
  + debuginfo package is valid
  + no static libraries nor .la files
  + no duplicated system libraries
    (libiberty is always static, bfd is target-specific, so neither of those 
can 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
  + _smp_mflags used
  + 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
+ spec file is legible (very clear actually, I don't know why everyone was 
scared away ;-) )
+ source matches upstream:
  MD5SUM: 6a9d529efb285071dad10e1f3d2b2967
  SHA1SUM: 5c80fd5657da47efc16a63fdd93ef7395319fbbf
+ builds on at least one arch (F7 i386 live system)
+ no known non-working arches, so no ExcludeArch needed
+ no missing BR (none needed)
+ 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
+ %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
+ all header files in -devel
+ no 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
  (Nitpick: But I recommend a:
  mkdir $RPM_BUILD_ROOT
  after the:
  rm -rf $RPM_BUILD_ROOT
  to prevent a potential symlink attack as pointed out by the OpenSUSE folks. 
Sure, building outside of mock is not recommended, but this doesn't mean people 
doing it and not redefining %{_tmpdir} deserve to get 0wn3d by the first script 
kiddie with a shell account on the machine.)
+ 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 (tested arm-gp2x-linux-as and 
arm-gp2x-linux-objdump on this trivial source:
add r1,r1,r1
add r1,r1,r1)
+ 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

Thanks for the review!


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

imported and build, closing.

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

Git done (by process-git-requests).