Spec URL: http://people.atrpms.net/~hdegoede/arm-linux-binutils.spec
SRPM URL: http://people.atrpms.net/~hdegoede/arm-linux-binutils-2.17.50.0.12-1.fc7.src.rpm
Description:
This is a Cross Compiling version of GNU binutils, which can be used to
assemble and link binaries for the arm-linux platform, instead of for the
native %{_arch} platform.
--
Notice to reviewers, I've removed the info / manpages and the PO files as these conflict with the native binutils. I think that this means that this package should have a "Requires: bintuils" to make sure the native binutils are always installed, especially for the PO files, I haven't done this yet as I'm not sure, but I think such a Requires should be added.

(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.

Hans, could you elaborate this change:
* Thu May 24 2007 Hans de Goede <j.w.r.degoede@hhs.nl> 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@hhs.nl> 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_Pagehttp://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@hhs.nl> 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.spechttp://people.atrpms.net/~hdegoede/arm-gp2x-linux-gcc-4.1.2-1.fc8.src.rpm
Thanks!

(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.

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