Re: Where do I override DISTRO_FEATURES?

[Thilo Fromm <fromm@dresearch-fe.de>]

Hello Denys,

>> >> I'm trying to remove an element from DISTRO_FEATURES (specifically
>> >> "ld-is-gold"), but I am unable to find the right spot to do it. The
>> >> distribution we're using (Angstrom, as it happens) sets this in
>> >> conf/distro/angstrom-v2012.x.conf. My machine configuration is the
>> >> wrong spot to modify DISTRO_FEATURES, since it will be processed
>> >> first. local.conf is not working, too.
>>
>> It's a backwards compatibility thing: we're bound to gcc-4.5 (we have
>> kernel build issues with newer gcc versions; we're nailed to
>> linux-2.6.37 thanks to lack of support by Texas Instruments) which
>> fails to detect the correct version of binutils GOLD (LD would work)
>> and therefore misses critical features which break the build later on.
>> I won't, however, try to convince the Angstrom guys to further support
>> ancient toolchains and make gold optional again just because of TI's
>> laziness.
>
> I think you are severely misinformed! Above issues (binutils-2.20/gcc-4.5
> requirement and gold ld problem with Thumb) were already fixed. I've been
> testing the builds with gcc-4.6 and binutils-2.22 for few weeks and even
> gcc-4.7 with gold linker since last week.

You're right, gcc-4.7 works well in the current setup. gcc-4.5,
however, does not detect the right binutils version with the GOLD
linker. GOLD version output is:

GNU gold (GNU Binutils 2.22) 1.11

The configure logic of gcc-4.5 would extract "1.11", not "2.22", for
the version number. Since Binutils 1.11 is ancient, some features of
gcc-initial are not set up correctly (gcc thinks the linker does not
support the "hidden" attribute). This breaks the build of
eglibc-initial later on.

I overslept the whole thing and I guess I'll just provide a patch to
gcc-4.5's configure so the GOLD linker version is detected correctly
instead of setting up my own distribution config.

> I don't know what layer you are
> using, but you may need to update, if you are using meta-ti.

meta-ti does not provide any toolchain anywhere. I have a toolchain
issue. The issue is with gcc-4.5 from meta-oe/toolchain-layer in
combination with binutils-2.22 from
openembedded-core/meta/recipes-devtools/.

Just in case you're curious, our layer structure is documented here:
<https://github.com/DFE/HidaV/wiki/Hidav-oe-layers>.

> Otherwise, if your platform is not directly supported by meta-ti, please send
> the bug report with the error message to meta-ti mailing list and I'll try to
> address it.

Which meta-ti mailing list are you talking about? There seem to be
many: this one, the arago lists, yocto-ti, ... And then again, it's a
toolchain issue (see above); meta-ti doesn't have toolchains.

> As of linux-2.6.37 for your specific platform - this one I can't help with,
> you would need to talk to your TI rep from the division that makes the
> platform and convince them to provide support for newer kernels.

I know, it's OK. We talked to TI a lot for quite a while, but our
realistic assessment from our TI experiences is that they'll never do
it. There are still a lot of issues with their old 2.6.37 kernel, TI
continually keeps breaking things. They don't have proper issue
trackers or mailing lists for communication with their developers.
From the reps and FAEs we'd get the occasional empty promise, but
that's it. Personally I think we went wrong with buying TI in the
first place.

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle