On 12/27/2012 09:29 PM, Mark Salter wrote:
On Thu, 2012-12-27 at 19:18 -0700, Al Stone wrote:
For those following along at home...
The nss-utils and nss-softokn packages now build properly for stage2.
They needed to have 64-bit builds enabled and nss-softokn has an
infinite loop that is fortunately only used in code needed for FIPS140
certification -- we can safely ignore this, for now at least.
In progress now are the nss and elfutils packages. Mark Slater is
working on elfutils.
And elfutils built with no changes but there were a few problems along
the way. stage2/local.conf has a problem which caused a build failure.
I ended up with this patch which comments out the distcc stuff I'm not
using and the problematic J=1 (should be J=-j1):
diff --git a/stage2/local.conf b/stage2/local.conf
index 6ab4645..2e848c7 100644
--- a/stage2/local.conf
+++ b/stage2/local.conf
@@ -1,11 +1,11 @@
-J=1
-DISTCC_HOSTS=localhost
-DISTCC_BACKOFF_PERIOD=0
-PATH=/stage2/distcc-bin:$PATH
+# J=1
+# DISTCC_HOSTS=localhost
+# DISTCC_BACKOFF_PERIOD=0
+# PATH=/stage2/distcc-bin:$PATH
PATH=/stage2/ccache-bin:$PATH
TARGET=aarch64-redhat-linux-gnu
RPMTARGET=aarch64-redhat-linux-gnu
TCONFIGARGS="--prefix=/usr --libdir=/usr/lib64 --enable-werror=no --enable-cxx --enable-languages=c,c++ --enable-threads=posix "
SUFFIX=64
-export J DISTCC_HOSTS DISTCC_BACKOFF_PERIOD PATH
-export TARGET RPMTARGET TCONFIGARGS SUFFIX
+# export J DISTCC_HOSTS DISTCC_BACKOFF_PERIOD
+export PATH TARGET RPMTARGET TCONFIGARGS SUFFIX
Argh. My bad. That's a typo in the stage1 script in bootstrap.git.
Fixed. It should indeed by J=-j1.
Also, there was a link error with my first attempt to build elfutils. A
failing configure test showed this problem:
--- test.c ---
char lzma_auto_decoder ();
int main()
{
return lzma_auto_decoder ();
}
---
# gcc test.c -llzma
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../../aarch64-redhat-linux-gnu/bin/ld: warning: librt.so.1, needed by /usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so, not found (try using -rpath or -rpath-link)
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../../aarch64-redhat-linux-gnu/bin/ld: warning: libpthread.so.0, needed by /usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so, not found (try using -rpath or -rpath-link)
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_join@GLIBC_2.16'
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_condattr_setclock@GLIBC_2.16'
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `clock_gettime@GLIBC_2.16'
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_create@GLIBC_2.16'
/usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_sigmask@GLIBC_2.16'
So this looks like something wrong in the static linker or maybe the
collect2 wrapper. I was able to work around it with:
diff --git a/etc/ld.so.conf b/etc/ld.so.conf
new file mode 100644
index 0000000..4d778f0
--- /dev/null
+++ b/etc/ld.so.conf
@@ -0,0 +1,2 @@
+/lib64
+/usr/lib64
The linker should look in those directories anyway, but for some reason
it isn't.
Hrm. I'll look into this as I try to update the toolchain over
the next couple of weeks (I'd just like to bring it up-to-date
with upstream changes and Alexandre Oliva's work). I looked
into it a little bit and it appears /etc/ld.so.conf is created
by the %install step in the glibc spec file, which is not where
I would have expected it. I've forced it to be created by the
stage1 bootstrap script, for now.
/lib64 should have been built into the toolchain paths; I may
have missed an occurrence somewhere when I rebuilt it a couple
of weeks back. I'll double check as I update the sources; we
have a workaround for now.
So, now how do I get the build into the upstream rootfs.git?
What I would like to do for the remainder of stage2 is just have
folks post patches here on the list, just like you did above.
I'll rebuild based on the patches and push changes into the git
tree as fast as I can. My thinking is that this way we can be
100% sure everything is built in a consistent environment for
stage2. For stage3, I don't think we'll need that constraint.
That being said, though, if this looks like it's going to slow
things down too much, let's re-examine it. Pulls and merges
from other git trees could also work. I don't want to end up
being a bottleneck in the process, and I am open to suggestions...
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@xxxxxxxxxx
-----------------------------------
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
