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

Why "armv5tejl-unknown-linux-gnueabi"? I think the ARM SIG is using "armv5tel-redhat-linux-gnueabi".

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

http://www.codesourcery.com/sgpp/lite/arm/portal/release830?@template=datasheet
http://www.codesourcery.com/sgpp/lite/arm/portal/release858?@template=datasheet

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.

(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

Just changed names:

http://peter.fedorapeople.org/armv5tel-fedora-linux-gnueabi-binutils.spec
http://peter.fedorapeople.org/armv5tel-fedora-linux-gnueabi-binutils-2.19.51.0.11-23.fc11.src.rpm

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.

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.

Yes I agree that "redhat" probably shouldn't be in there. I am curious to see what comes of mailing to the list.

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:

http://www.mail-archive.com/autoconf@gnu.org/msg00969.html
http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=3

Here is a brief answer for my question from Ralf Corsepius:
http://thread.gmane.org/gmane.linux.redhat.fedora.arm/191/focus=117221

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

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/41315
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/56709

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

http://peter.fedorapeople.org/armv5tel-unknown-linux-gnueabi-binutils.spec
http://peter.fedorapeople.org/armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-30.fc11.src.rpm

Koji scratchbuild (in progress, atm):

http://koji.fedoraproject.org/koji/taskinfo?taskID=1550270

Sync with the latest binutils from F-12.

http://peter.fedorapeople.org/armv5tel-unknown-linux-gnueabi-binutils.spec
http://peter.fedorapeople.org/armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-35.fc12.src.rpm

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.

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)

[1]http://lists.fedoraproject.org/pipermail/arm/2010-November/000727.html

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-2.19.51.0.14-35.fc14.src.rpm): open (x86-04.phx2.fedoraproject.org)
  2887016 buildArch (armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-35.fc14.src.rpm, i686): open (x86-13.phx2.fedoraproject.org)
  2887015 buildArch (armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-35.fc14.src.rpm, x86_64): open (x86-18.phx2.fedoraproject.org)
  2887016 buildArch (armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-35.fc14.src.rpm, i686): open (x86-13.phx2.fedoraproject.org) -> closed
  0 free  2 open  1 done  0 failed
  2887015 buildArch (armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-35.fc14.src.rpm, 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-2.19.51.0.14-35.fc14.src.rpm): open (x86-04.phx2.fedoraproject.org) -> closed
  0 free  0 open  3 done  0 failed

2887014 build (dist-f14, armv5tel-unknown-linux-gnueabi-binutils-2.19.51.0.14-35.fc14.src.rpm) completed successfully

I'm no longer interested in maintaining this. Sorry.