[oe] [RFC]: Toolchain build sequence alteration.

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Khem Raj wrote:
> Hi,
> 
> I have faced a problem which took me a while to understand. I was
> working on uclibc and therefore I needed to rebuild uclibc many times
> and thats when I saw this issue.
> 
> When I rebuilt only uclibc after a complete rebuild. Suddenly in the new
> root file system with new uclibc application wont load properly
> complaining about missing symbols (symbols were from libgcc like
> __aeabi_*)
> 
> Looking at it the problem is that right now we build uclibc with a
> intermediate compiler(gcc-cross-initial) which is build with
> --disable-shared. We use this uclibc and its headers and dev-libs and we
> rebuild a fresh full cross-gcc (gcc-cross) with -shared-lib support to
> build the rest of system/image.
> 
> Therefore the uclibc we build in subsequent time will be build using
> cross-gcc and not cross-gcc-initial. 
> 
> What happens is that some of the libgcc symbols get linked into
> uclibc/libc.so when it is built with a gcc without shared lib
> support(gcc-initial). When building whole sytem different
> applications(e.g. gawk) which need these symbols link as if they will
> get these symbols from libc.so at runtime, which is correct if I ran
> with the first time build uclibc but when I rebuilt just uclibc all
> these symbols were not being resolved by ld.so because there were no
> DT_NEEDED entry for libgcc_s.so in the application binary as it was
> build to get these symbols from libc.so, but rebuilt uclibc now do not
> export these symbols because it was built with a compiler that supports
> shared-libs(cross-gcc).
> 
> Then I went to see the toolchain build order. Currently we do
> 
> cross-binutils -> kernel-headers -> uclibc-headers -> cross-gcc
> (--disable-shared) -> uclibc -> cross-gcc
> 
> I think this can be improved and I implemented the following steps.
> 
> cross-binutils -> cross-gcc (--disable-shared) -> kernel-headers ->
> eglibc/glibc/uclibc headers + startup files + dummy libc.so -> cross-gcc
> (--enable-shared) -> glibc/eglibc/uclibc -> cross-gcc
> 
> These steps work same for uclibc as well as glibc/eglibc toolchains
> irrespective of architectures.
> 
> These steps work for both NPTL and LinuxThreads toolchains. 
> 
> Given we use these steps, we will have same toolchain build sequence in
> all circumstances and will help to reduce the current complex toolchain
> builds we have.
> 
> We will not need glibc-intermediate step and we will introduce a new
> step called cross-gcc-intermidiate.
> 
> I have so far tested this sequence on arm uclibc and it works well and
> understandably solves the issue I am seeing.
> 
> I have used this sequence in external scripts to build toolchains too
> and it has worked well.
> 
> Now, I have a prototype patch for uclibc-0.9.29+gcc-4.2.4 based
> toolchain which I am attaching here.
> 
> If we agree on this aproach I can go ahead and do the same for
> eglibc/glibc toolchains too.
> 
> I have not tested it on older compiler/library combinations but I think
> it will work there too as I have build various combinations in the past
> with same sequence outside OE.
> 
> Comments and feedback is welcome.
> 
> Thanks
> 
> -Khem

Hello All,

I have meanwhile developed a relatively complete patch. I have tested it on uclibc-0.9.29 glibc_2.6.1 and eglibc_svn and all have worked well. I have also booted the console-images produced.

Here is the revised patch.

As its a fundamental change and its not possible for me to test all combos. Any testing will be highly appreciated.

Thanks

- -Khem

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIfaz+HnJKy6V6em4RAlQmAJ9YyF1UTn4zhbZ6uTcoS/IKr05uyACdHyhu
a/DEZHuwPPCR0wR5T4NXaMY=
=X5/H
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oe-new-toolchain-build-sequence.patch
Type: text/x-diff
Size: 60554 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20080716/a36f98a0/attachment-0002.bin>