Spec URL: http://peter.fedorapeople.org/armv5tejl-unknown-linux-gnueabi-binutils.spec SRPM URL: http://peter.fedorapeople.org/armv5tejl-unknown-linux-gnueabi-binutils-2.19.51.0.11-23.fc11.src.rpm 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 http://koji.fedoraproject.org/koji/taskinfo?taskID=1456340 rpmlint is silent: [petro@Sulaco ppc]$ rpmlint armv5tejl-unknown-linux-gnueabi-binutils-2.19.51.0.11-23.fc11.ppc.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [petro@Sulaco ppc]$
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.