[fedora-arm] [AArch64] Stage2 updates

[Al Stone]

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 at GLIBC_2.16'
> /usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_condattr_setclock at GLIBC_2.16'
> /usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `clock_gettime at GLIBC_2.16'
> /usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_create at GLIBC_2.16'
> /usr/lib64/gcc/aarch64-redhat-linux-gnu/4.7.2/../../../liblzma.so: undefined reference to `pthread_sigmask at 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 at redhat.com
-----------------------------------