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:[email protected] 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
