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.
Latest rootfs and bootstrap scripts have all been uploaded to their respective git repos.
Stage2 details: https://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage2Notes
AArch64 bootstrap project info: https://fedoraproject.org/wiki/Architectures/ARM/AArch64
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
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.
So, now how do I get the build into the upstream rootfs.git?
--Mark
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...
On Sat, 2012-12-29 at 15:01 -0700, Al Stone wrote:
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.
I don't really think it is general library search paths which are the problem. It is the case where the static linker needs to pull in a library because of a DT_NEEDED tag in some other library it pulled in. In this situation, I think the static linker tries to act like the dynamic linker would wrt searching for the libraries. So adding explicit -L/usr/lib64 doesn't help. /etc/ld.so.cache is consulted for this special search so I used that as a workaround. But /usr/lib64 should not need to be in /etc/ld.so.cache, so there is probably some minor thing missing from the binutils sources or in the configure command used to build it.
On 12/29/2012 03:26 PM, Mark Salter wrote:
On Sat, 2012-12-29 at 15:01 -0700, Al Stone wrote:
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.
I don't really think it is general library search paths which are the problem. It is the case where the static linker needs to pull in a library because of a DT_NEEDED tag in some other library it pulled in. In this situation, I think the static linker tries to act like the dynamic linker would wrt searching for the libraries. So adding explicit -L/usr/lib64 doesn't help. /etc/ld.so.cache is consulted for this special search so I used that as a workaround. But /usr/lib64 should not need to be in /etc/ld.so.cache, so there is probably some minor thing missing from the binutils sources or in the configure command used to build it.
Ah. Yeah, probably true. I'll make sure to double check binutils.
Al, Mark,
I like the idea of keeping patches on the list. Please. Also, yea, that lib64 library path config looks suspect - I am sure Al will find that one quickly :) I shall return to getting the FPGA running on Wed and then help with bootstrap in spare cycles. Right now, I am enjoying the holiday :)
Jon.
[Apologies if this arrives multiple times, apparently the mailinglist just eats messages from non-subscribers...]
On Thu, Dec 27, 2012 at 11:29:14PM -0500, Mark Salter wrote:
On Thu, 2012-12-27@19:18 -0700, Al Stone wrote:
In progress now are the nss and elfutils packages. Mark Slater is working on elfutils.
And elfutils built with no changes
Glad to see it builds just fine. Note that there is some porting required to make it really work for ARM64 ELF binaries. As is it should work fine for all generic ELF stuff and the existing arches (all elfutils libraries work cross-arch). It shouldn't be too much work doing a full port. Basically elfutils needs an updated elf.h from glibc and some definitions in backends/ for ARM64 specific ELF relocations and DWARF register mappings. And ideally there is a new ARM64 specific test file added so the port can be tested on other platforms too. The recent Tilera TILE-Gx port might be the easiest way to see what kind of things are necessary for full architecture support: https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-August/thread.h...
Ideally make check should show zero failures. There are both cross-arch and self-tests that check things look fine. Do you have results published somewhere?
Please feel free to contact the main elfutils developer list: https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel elfutils-devel@lists.fedorahosted.org
Thanks,
Mark
-
Al Stone -
Jon Masters -
Mark Salter -
Mark Wielaard