On 09/04/2014 10:38 AM, Gordan Bobic wrote: > On 09/03/2014 09:52 PM, Jacco Ligthart wrote: >> >> I remember seeing requests for ARM hardware on the CentOS list. Is there >> any progress there? It might be much easier if we could use their koji. > > CentOS project won't be doing an EL6 port, they are working on the EL7 > port. > > Also, having looked into this at some length, Koji is an immensely > complicated, very patchy piece of software with little or no practical > use and no advantages over a few bash scripts containing 100 lines or > less. I use such scripts and mock. > > There is a commonly held misconception that Koji performs dependency > checking, and thus can speed up builds of large package sets. It does > no such thing. I keep meaning to write something that will analyze all > the spec files and attempt to come up with a source and binary > dependency tree, but it is not a trivial piece of work. CPU time is > cheap (even when it's slow ARMs) and man-hours are expensive, so > nothing happens. I was not thinking about dependencies, I was thinking about workflow. What still needs to be done? what was the build log of a previous failed build? etc. I now tend to "fiddle" with the .spec and sometimes loose track of what I've done and why it failed, etc.
>>>> next I'll try to build gcc and glibc. >>> >>> Best of luck - I never managed to get glibc to build. There are extra >>> ARM patches required (look at the F12/F13 glibc, which is the most >>> recent distribution that ships with glibc 2.12 - it comes with an >>> extras source tar ball). >>> >>> I'll be more interesting to see the documentation of you manage to get >>> it to work, though. OK, here goes. I used the following: - srpm from upstream - the patch from the redsleeve wiki (http://ftp.redsleeve.org/pub/patches/glibc-2.12-1.25.el6.src.rpm.patch) - glibc-ports from fedora (http://pkgs.fedoraproject.org/repo/pkgs/glibc/glibc-ports-2.12-26-gcf64098.tar.xz/) - extra patch from glibc's git (https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e057a1b5930ec538c2b8abbba700a436ef2c81d5) The redsleeve patch of course doesn't apply cleanly, but it is obvious what needs to be changed where. The glibc-ports stuff is not in the redsleeve patch, so I went looking for the most recent glibc-ports for 2.12 (2.12-54-gbd44238). This broke the compile, so I went back to 2.12-26-gcf64098. The error I saw was: In file included from ../../glibc-ports-2.12-54-gbd44238/sysdeps/arm/eabi/ftestexcept.c:24: ../../glibc-ports-2.12-54-gbd44238/sysdeps/unix/sysv/linux/arm/ldsodefs.h:41:1: warning: "MORE_ELF_HEADER_DATA" redefined In file included from ../../glibc-ports-2.12-54-gbd44238/sysdeps/unix/sysv/linux/arm/ldsodefs.h:23, from ../../glibc-ports-2.12-54-gbd44238/sysdeps/arm/eabi/ftestexcept.c:24: ../sysdeps/unix/sysv/linux/ldsodefs.h:64:1: warning: this is the location of the previous definition ../../glibc-ports-2.12-54-gbd44238/sysdeps/arm/eabi/ftestexcept.c:44: error: '__EI_fetestexcept' aliased to undefined symbol '__GI_fetestexcept' With the older glibc-ports I got another error later in the build process: /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/resolv/gethnamaddr.c:366: undefined reference to `__stack_chk_guard' /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv/libresolv_pic.a(gethnamaddr.os): In function `res_gethostbyaddr': /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/resolv/gethnamaddr.c:783: undefined reference to `__stack_chk_guard' /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv/libresolv_pic.a(gethnamaddr.os): In function `*__GI_res_gethostbyname2': /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/resolv/gethnamaddr.c:636: undefined reference to `__stack_chk_guard' /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv/libresolv_pic.a(res_debug.os): In function `__p_cdnname': /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/resolv/res_debug.c:298: undefined reference to `__stack_chk_guard' /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/resolv/res_debug.c:297: undefined reference to `__stack_chk_guard' /builddir/build/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv/libresolv_pic.a(res_debug.os):/builddir/build/BUILD/glibc-2.12-2-gc4ccff1/resolv/res_debug.c:343: more undefined references to `__stack_chk_guard' follow This looked a lot like the other error messages in the redhat bugzilla, so that I thought that it probably has the same issue. After a lot of fiddling I saw the referenced patch at the glibc git repo. The patch immediately before it (to the same Makefile) is included in upstream's srpm. long story short: I got glibc build, the srpm, the rpm's and the patch can all be found under http://cdn.opensxce.org/redsleeve/el6/updates-testing/ I have not tried to build anything against it, but a raspi test image boots with it :) other observations: - not sure if we should upgrade to a more recent glibc-ports. I did not try any of the others and I saw nothing in the Changelog which hinted that updating is necessary. - the part of the redsleeve patch regarding libc_cv_gcc_static_libgcc seems not to do any thing. I left it in out of laziness. It adds a harmless warning to the buildlog, but I did not find the added build flags in the buildlog: checking whether GCC supports -static-libgcc... ../configure: line 5596: -W,l:/builddir/build/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/libc.a: No such file or directory >> gcc build fairly easy. It needed actually less patches than previously. >> All the libgcc_post_upgrade stuff is now in the upstream SRPM. The patch >> I used is here: >> http://cdn.opensxce.org/redsleeve/el6/updates-testing/patches/ > > I found I didn't need any patches to get the newer gcc to build. The > problem is that it didn't work. It works good enough to compile glibc :) Jacco _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
