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