Bug 509798 - Review Request: armv5tel-unknown-linux-gnueabi-binutils - A GNU collection of binary utilities
Summary: Review Request: armv5tel-unknown-linux-gnueabi-binutils - A GNU collection of...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-07-06 09:49 UTC by Peter Lemenkov
Modified: 2012-06-29 22:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-07-25 06:26:39 UTC
Type: ---

Attachments (Terms of Use)
extend CARGS with %if-%else instead of putting it as args to %configure directly (1.11 KB, patch)
2011-03-05 14:17 UTC, Niels de Vos
no flags Details | Diff

Description Peter Lemenkov 2009-07-06 09:49:40 UTC
Spec URL: http://peter.fedorapeople.org/armv5tejl-unknown-linux-gnueabi-binutils.spec
SRPM URL: http://peter.fedorapeople.org/armv5tejl-unknown-linux-gnueabi-binutils-

Description: Binutils is a collection of binary utilities, including ar (for
creating, modifying and extracting from archives), as (a family of GNU
assemblers), gprof (for displaying call graph profile data), ld (the
GNU linker), nm (for listing symbols from object files), objcopy (for
copying and translating object files), objdump (for displaying
information from object files), ranlib (for generating an index for
the contents of an archive), readelf (for displaying detailed
information about binary files), size (for listing the section sizes
of an object or archive file), strings (for listing printable strings
from files), strip (for discarding symbols), and addr2line (for
converting addresses to file and line).

This is a first my attempt to create cross-binutils suitable for Fedora ARM SIG. It's just a plain binutils.spec from main Fedora repository with only two additions - "ExcludeArch: armv5tejl" (this should be properly fixed and added to main Fedora's binutils.spec) and "%define binutils_target armv5tejl-unknown-linux-gnueabi" (not sure how to add it properly - using file with rpm-macro in something like armv5tejl-unknown-linux-gnueabi-filesystem or so).

Anyway, feel free to blame me, send me kudos for this or add other suggestions and comments here.

Here is a koji scratchbuild


rpmlint is silent:

[petro@Sulaco ppc]$ rpmlint armv5tejl-unknown-linux-gnueabi-binutils- 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
[petro@Sulaco ppc]$

Comment 1 Jason Tibbitts 2009-07-06 17:27:55 UTC
Any reason the name is so terribly long?  We already have msp430-binutils, spu-binutils and mingw32-* which seems to give precedence to armv5ejl-binutils, unless you expect to actually need to package binutils for some OS other than linux or some particular variant other than "unknown".

Comment 2 Adam Goode 2009-07-07 01:23:50 UTC
Why "armv5tejl-unknown-linux-gnueabi"? I think the ARM SIG is using "armv5tel-redhat-linux-gnueabi".

Comment 3 Peter Lemenkov 2009-07-07 08:42:42 UTC
(In reply to comment #1)
> Any reason the name is so terribly long?  We already have msp430-binutils,
> spu-binutils and mingw32-* which seems to give precedence to armv5ejl-binutils,
> unless you expect to actually need to package binutils for some OS other than
> linux or some particular variant other than "unknown".  

I'm afraid that these cross-tools are named wrong (except mingw, which is different). Cross-toolchain should inform potential user about processor architecture it designed for (armv5tejl), target (linux) and binary format (GNU EABI). I think, that only "unknown" part may be omitted, but I feel that it's better to rename it to something like "fedora" (not "redhat", as Adam suggested).

For example, if someone will develop bootloaders for arm-platforms, then he should obtain two different cross-toolchains. One - for developing Linux kernel and user-space applications (which is exactly what I submitted) and another - for developing "bare-metal" applications, such as bootloaders. See these links for the details:


That's why we should specify explicitly what exact type of cross-toolchains we're providing.

I didn't dig into details yet, but it seems that conventional gcc tries to link by default with libraries and routines, which cannot be used at the boot-stage (for example, in my case, it tries to link with code for trapping division by zero). I would like to remind you, that I'm still not an authoritative person in developing for ARM, so I can be wrong in some particular details.

Comment 4 Peter Lemenkov 2009-07-07 09:22:15 UTC
(In reply to comment #2)
> Why "armv5tejl-unknown-linux-gnueabi"? I think the ARM SIG is using
> "armv5tel-redhat-linux-gnueabi".  

Yes, naming scheme is wrong. However, I think that proper scheme will be armv5tel-fedora-linux-gnueabi

Comment 6 Adam Goode 2009-07-07 13:03:22 UTC
The ARM SIG has chosen armv5tel-redhat-linux-gnueabi, you should probably stay consistent with them and ask them to change it if you think it is incorrect.

Comment 7 Peter Lemenkov 2009-07-07 13:28:46 UTC
I'm afraid, that you're wrong - no naming scheme was chosed so far (at least they didn't do it in open manner). Moreover, I suspect that using name "redhat" is not suitable. First - it's a trademark, second - we are building Fedora, not the RHEL.

Actually, maybe is it better to change this part to something neutral? I did some checks - here are valid gcc naming schemes:

i686-pc-linux-gnu (gcc for F-10, i386)
powerpc-unknown-linux-gnu (gcc for F-11, ppc)
x86_64-unknown-linux-gnu (gcc for x86_64, CentOS 5)
armv5tejl-unknown-linux-gnueabi (F-10 for ARM on my arm-machine)

On the other hand, if we'll add branches for EPEL, then my naming scheme (armv5tel-redhat-linux-gnueabi) will be improper.

I'll ask in mail-lists.

Comment 8 Adam Goode 2009-07-07 13:41:18 UTC
Yes I agree that "redhat" probably shouldn't be in there. I am curious to see what comes of mailing to the list.

Comment 9 Peter Lemenkov 2009-07-28 13:32:42 UTC
Ok, after some googling, I suspect that the only proper way is to use "unknown" as vendor field, since it definitely shows, that our cross-toolchain intended for wide use and not locked to some particular hardware.

See also these links:


Here is a brief answer for my question from Ralf Corsepius:

Here are the previous Fedora-related discussions about cross-compiling in general:


Ok, renamed back and updated to the latest "main" binutils:


Comment 10 Peter Lemenkov 2009-07-28 13:40:58 UTC
Koji scratchbuild (in progress, atm):


Comment 12 Jason Tibbitts 2010-11-03 12:53:57 UTC
This fails to build for me:

config.status: creating Makefile
+ --with-sysroot=/usr/armv5tel-unknown-linux-gnueabi/sys-root --program-prefix=armv5tel-unknown-linux-gnueabi- --disable-shared --disable-werror --with-bugurl=http://bugzilla.redhat.com/bugzilla/
/var/tmp/rpm-tmp.06Q1VG: line 78: --with-sysroot=/usr/armv5tel-unknown-linux-gnueabi/sys-root: No such file or directory

That seems to be missing a command there.  I do not think you can split the argument list for the configure script with conditionals in the middle in the way you're trying to do it.

Failing scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2573784

Also, have you contacted the ARM secondary arch folks about this?  (You may be working with them; I can't really tell.)  Some input from them might be useful.

Please clear the Whiteboard if providing a version which builds.

Comment 13 Rich Mattes 2010-12-03 20:43:38 UTC
The specfile in the SRPM has the --enable-targets=%{_host} line commented out, which is causing the build to fail.  I don't know if it's supposed to be enabled or not, but the package builds without the # and without the entire line.

There's some recent interest on the ARM mailing list for getting a cross-compiler working[1].  Included are patches for the latest rawhide binutils and gcc, I don't know if they're helpful for you.

I think it would be worth starting a discussion over on the ARM list about naming conventions for cross tools.  Personally, I think the cross tools should follow the conventions that the native tools use (it looks like they're all using %{_target_platform}, which evaluates to i686-redhat-linux-gnu on fedora 13)


Comment 14 Niels de Vos 2011-03-05 14:17:36 UTC
Created attachment 482436 [details]
extend CARGS with %if-%else instead of putting it as args to %configure directly

With this patch for the spec-file, the binutils compile on a local Fedora-14.x86_64.

Started a scratch-build with an updated src.rpm:
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2887014
Watching tasks (this may be safely interrupted)...
2887014 build (dist-f14, armv5tel-unknown-linux-gnueabi-binutils- open (x86-04.phx2.fedoraproject.org)
  2887016 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, i686): open (x86-13.phx2.fedoraproject.org)
  2887015 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, x86_64): open (x86-18.phx2.fedoraproject.org)
  2887016 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, i686): open (x86-13.phx2.fedoraproject.org) -> closed
  0 free  2 open  1 done  0 failed
  2887015 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, x86_64): open (x86-18.phx2.fedoraproject.org) -> closed
  0 free  1 open  2 done  0 failed
2887014 build (dist-f14, armv5tel-unknown-linux-gnueabi-binutils- open (x86-04.phx2.fedoraproject.org) -> closed
  0 free  0 open  3 done  0 failed

2887014 build (dist-f14, armv5tel-unknown-linux-gnueabi-binutils- completed successfully

Comment 15 Peter Lemenkov 2011-07-25 06:26:39 UTC
I'm no longer interested in maintaining this. Sorry.

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