On 2014-09-08 22:20, Jacco Ligthart wrote:
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.
I do this using simple lock/status/log files with mock. If mock returns
success status, all is well. If it returns a failure status, create a
$srpm.fail file. Always keep the root-build (to detect missing
dependencies) and package build logs. I keep this on an uncached
NFS share, which is mounted to all the build nodes. It works very
well for me.
It's 50 lines of bash and covers all of the useful functionality of
mock without the complication of koji.
If there is a killer feature in koji that I'm missing, please, do
point it out, but having looked at it quite extensively, I have
not found any that justify the complexity.
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 :)
That's quite awesome. What about other ports versions between 26 and 54?
When I'm back in the lab in 10 days or so I'll set up a few builders
in the DMZ where we can kick off a full rebuild of all the packages
and see what (if anything) breaks when building against the new
glibc with the new gcc. I'm a little concerned about the newer gcc
because I'm quite certain I remember that it caused FTBFS issues
in a number of packages, or I wouldn't have backed it out of my
build repositories.
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.
You could say that about a LOT of updating, though.
- 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
I don't remember why this was necessary. It is possible it was a fix
for something that made another dynamically linked package break. This
kind of thing happens. For example, there is a bug in pth that manifests
in packages linking against it breaking, but pth build itself works.
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 :)
glibc doesn't exercise fully all of the gcc paths, e.g. it could be a
bug in the C++ part. Proceed with care.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
