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.
--
Sent from my iPad
On Dec 29, 2012, at 17:02, Al Stone <ahs3@xxxxxxxxxx> wrote:
> 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
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
