Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC]: Toolchain build sequence alteration.
Date: Wed, 16 Jul 2008 10:46:26 +0200	[thread overview]
Message-ID: <g5kch2$egl$1@ger.gmane.org> (raw)
In-Reply-To: <487DACFF.5010504@gmail.com>

Khem Raj wrote:
> -----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 for your work on this!

I have a few comments on the patch without having tested it:


--- conf/distro/angstrom-2008.1.conf 
f64ebcf55e85b504d3be169befac3c7981aa74d9
+++ conf/distro/angstrom-2008.1.conf 
8703f595671685f632e51c96d1be75cdceddfe83
@@ -70,9 +70,8 @@ PREFERRED_VERSION_linux-libc-headers 	=
  PREFERRED_VERSION_linux-libc-headers 	= "2.6.23"

  #Prefer glibc 2.6 and uclibc 0.9.29, these have had the most testing.
-PREFERRED_VERSION_glibc 		?= "2.6.1"
-PREFERRED_VERSION_glibc-intermediate 	?= "2.6.1"
-PREFERRED_VERSION_glibc-initial 	?= "2.6.1"
+PREFERRED_VERSION_glibc 		?= "2.3.6"
+PREFERRED_VERSION_glibc-initial 	?= "2.3.6"

  #Everybody else can just use this:
-ANGSTROM_GCC_VERSION 			?= "4.2.4"
+ANGSTROM_GCC_VERSION 			?= "3.4.4"

@@ -123,6 +122,7 @@ PREFERRED_PROVIDER_virtual/${TARGET_PREF
  # Virtuals:
  PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = "binutils-cross"
  PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial = 
"gcc-cross-initial"
+PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate = 
"gcc-cross-intermediate"
  PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = "gcc-cross"
  PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "gcc-cross"


You probably only want the PREFERRED_PROVIDER bit, not changing angstrom 
back to the dark ages :)

You also change handling of ctr*.o, but that was intended, right?

I see no obvious errors besides the above, but as I said, I haven't 
tested it.

regards,

Koen





  reply	other threads:[~2008-07-16  8:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15  1:58 [RFC]: Toolchain build sequence alteration Khem Raj
2008-07-15  7:34 ` Henning Heinold
2008-07-16  8:10 ` Khem Raj
2008-07-16  8:46   ` Koen Kooi [this message]
2008-07-16 15:27     ` Khem Raj
2008-07-16 20:43   ` Leon Woestenberg
2008-07-17  8:43     ` Khem Raj
2008-07-22  0:28     ` Khem Raj
     [not found]     ` <20080720014112.GA13759@oberlord>
2008-07-23  9:04       ` Khem Raj
2008-07-24  9:10         ` Richard Purdie
2008-07-24 16:05           ` Richard Purdie
2008-07-24 16:18             ` Koen Kooi
2008-07-25  7:33               ` Khem Raj
2008-07-25 10:01                 ` Henning Heinold
2008-07-25 16:06                   ` Khem Raj
2008-07-28  6:27           ` SH7760 Problems Stefano Regno
2008-08-02 12:03 ` [RFC]: Toolchain build sequence alteration Koen Kooi
2008-08-02 15:14   ` Phil Blundell
2008-08-02 15:45     ` Koen Kooi
2008-08-03  2:47       ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='g5kch2$egl$1@ger.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox