| 1 |
On 19 Jan 2016 14:44, Alex McWhirter wrote: |
| 2 |
> On 01/19/2016 02:38 PM, Mike Frysinger wrote: |
| 3 |
> > On 19 Jan 2016 14:16, Alex McWhirter wrote: |
| 4 |
> >> I found the issue here, but i'm not sure how to handle it. The logic in |
| 5 |
> >> common.eblit is wrong for sparc64. See below |
| 6 |
> >> |
| 7 |
> >> <snip> |
| 8 |
> >> local cpu |
| 9 |
> >> case ${CTARGET} in |
| 10 |
> >> sparc64-*) |
| 11 |
> >> </snip> |
| 12 |
> >> |
| 13 |
> >> Pulling from CHOST and basing CTARGET off of that is probably not the |
| 14 |
> >> best idea for sparc64 because the result will always be 64 bit. Hence |
| 15 |
> >> why we have build errors when attempting 32bit multi lib. |
| 16 |
> > |
| 17 |
> > i don't think that's the case. if you look up a level: |
| 18 |
> > - setup_target_flags is only called by setup_flags |
| 19 |
> > - setup_flags is only called by setup_env |
| 20 |
> > - setup_env first calls multilib_env |
| 21 |
> > |
| 22 |
> > so multilib_env should have set up the state such that CTARGET reflects |
| 23 |
> > the current ABI (e.g. a sparc-* tuple) rather than the native one (e.g. |
| 24 |
> > always sparc64-*). |
| 25 |
> > |
| 26 |
> >> Also, mcpu=ultrasparc will set the target to v9a and all sparv9 boxes |
| 27 |
> >> are backwards compatible to v9a. Ultrasparc being the lowest common |
| 28 |
> >> denominator for 64 bit means we can clean up the wild card a bit. That's |
| 29 |
> >> not a big deal really, forcing v9a should have a similar effect. |
| 30 |
> > |
| 31 |
> > the reason that append is there is to workaround (imo) a build bug rather |
| 32 |
> > than something we really want to be doing. if we did it all the time, it |
| 33 |
> > would clobber existing flags someone might have set. |
| 34 |
> > |
| 35 |
> >> I need to research the specific targets a bit and maybe i can come up |
| 36 |
> >> with an answer. Do we have {$ABI} here? |
| 37 |
> > |
| 38 |
> > we have $ABI, but it should have already been selected (see my call |
| 39 |
> > graph above) |
| 40 |
> > |
| 41 |
> > -mike |
| 42 |
> |
| 43 |
> Perhaps we have a bug somewhere else then? |
| 44 |
> |
| 45 |
> The output below is from a GLIBC build |
| 46 |
> |
| 47 |
> * Configuring glibc for nptl |
| 48 |
> * ABI: sparc32 |
| 49 |
> * CBUILD: sparc64-unknown-linux-gnu |
| 50 |
> * CHOST: sparc64-unknown-linux-gnu |
| 51 |
> * CTARGET: sparc64-unknown-linux-gnu |
| 52 |
> * CBUILD_OPT: sparc64-unknown-linux-gnu |
| 53 |
> * CTARGET_OPT: sparc64-unknown-linux-gnu |
| 54 |
> * CC: sparc64-unknown-linux-gnu-gcc -m32 |
| 55 |
> * LD: |
| 56 |
> * ASFLAGS: |
| 57 |
> * CFLAGS: -mcpu=ultrasparc -pipe -fcall-used-g6 -O2 |
| 58 |
> -fno-strict-aliasing |
| 59 |
> * CPPFLAGS: |
| 60 |
> * CXXFLAGS: -mcpu=ultrasparc -pipe -fcall-used-g6 -O2 |
| 61 |
> -fno-strict-aliasing |
| 62 |
> * LDFLAGS: -Wl,-O1 -Wl,--as-needed |
| 63 |
> * Manual CC: sparc64-unknown-linux-gnu-gcc -m32 -Wl,-O1 |
| 64 |
> -Wl,--as-needed |
| 65 |
> |
| 66 |
> |
| 67 |
> multilib_env is pulling the in ABI correctly, but not CTARGET. Unless we |
| 68 |
> should be setting CTARGET_$ABI in the profile? |
| 69 |
> |
| 70 |
> I have the CHOST's below in the profile now. |
| 71 |
> |
| 72 |
> CHOST_sparc32="sparc-unknown-linux-gnu" |
| 73 |
> CHOST_sparc64="sparc64-unknown-linux-gnu" |
| 74 |
|
| 75 |
if you delete that CHOST override, do the *_OPT values end up being |
| 76 |
sparc-* ? if not, put `set -x` at the top of setup_env and `set +x` |
| 77 |
at the bottom of setup_env and send that log over. sparc is the only |
| 78 |
one that sets CTARGET_OPT in this sub-case, so there might be a bug |
| 79 |
in there. unfortunately we can't get away from overriding the tuple |
| 80 |
for glibc since user's can't really change it and glibc itself does |
| 81 |
no probing :(. my preference otherwise would be to delete this block |
| 82 |
of code entirely. |
| 83 |
-mike |
Archives