Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 509798

Summary: Review Request: armv5tel-unknown-linux-gnueabi-binutils - A GNU collection of binary utilities
Product: [Fedora] Fedora Reporter: Peter Lemenkov <lemenkov>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: adam, bjohnson, fedora-package-review, herrold, notting, richmattes
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-25 06:26:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 201449, 245418    
Description Flags
extend CARGS with %if-%else instead of putting it as args to %configure directly none

Description Peter Lemenkov 2009-07-06 09:49:40 UTC
Spec URL:

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=
/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:

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:
Watching tasks (this may be safely interrupted)...
2887014 build (dist-f14, armv5tel-unknown-linux-gnueabi-binutils- open (
  2887016 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, i686): open (
  2887015 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, x86_64): open (
  2887016 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, i686): open ( -> closed
  0 free  2 open  1 done  0 failed
  2887015 buildArch (armv5tel-unknown-linux-gnueabi-binutils-, x86_64): open ( -> closed
  0 free  1 open  2 done  0 failed
2887014 build (dist-f14, armv5tel-unknown-linux-gnueabi-binutils- open ( -> 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.