linaro-toolchain

linaro-toolchain@lists.linaro.org

7 participants
5647 discussions

condition_variable_any missing from libstdc

by Mark Pupilli

---------- Forwarded message ---------- From: Mark Pupilli <mpupilli(a)gmail.com> Date: 17 November 2013 14:07 Subject: condition_variable_any missing from libstdc To: linaro-toolchain(a)lists.linaro.org Hi, I sent this message a week ago but I don't think I was subscribed to the list correctly. Apologies if it is repeated (it doesn't show in the archive). I have a problem with my cross build of (Linaro GCC 4.8-2013.10). I get the following runtime linker errors regarding condition_variable_any: "relocation error: /usr/local/lib/librobolib.so: symbol _ZNSt22condition_variable_anyC1Ev, version GLIBCXX_3.4.11 not defined in file libstdc++.so.6 with link time reference" If I examine my built version of libstdc with readelf I get the following output: $ readelf -s ./src/.libs/libstdc++.so.6 | grep condition 10383: 000c58d8 68 FUNC LOCAL DEFAULT 11 _ZNSt15error_conditionC1E 10818: 000c58d8 68 FUNC LOCAL DEFAULT 11 _ZNSt15error_conditionC2E 10837: 000c5944 40 FUNC LOCAL DEFAULT 11 _ZNKSt15error_condition8c 10942: 000c591c 40 FUNC LOCAL DEFAULT 11 _ZNKSt15error_condition5v Where as with the apt-get installed 4.6 version of the toolchain shows: $ readelf -s /usr/arm-linux-gnueabi/lib/libstdc++.so.6 | grep condition 777: 000523b1 12 FUNC GLOBAL DEFAULT 12 _ZNSt22condition_variable@@GLIBCXX_3.4.11 929: 000522f1 104 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 1037: 000523b1 12 FUNC GLOBAL DEFAULT 12 _ZNSt22condition_variable@@GLIBCXX_3.4.11 1198: 000522f1 104 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 1686: 00052385 14 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 2166: 00052359 12 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 2438: 00052359 12 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 2685: 00052365 16 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 3186: 00052395 26 FUNC GLOBAL DEFAULT 12 _ZNSt22condition_variable@@GLIBCXX_3.4.11 3448: 00052395 26 FUNC GLOBAL DEFAULT 12 _ZNSt22condition_variable@@GLIBCXX_3.4.11 3643: 00052375 14 FUNC GLOBAL DEFAULT 12 _ZNSt18condition_variable@@GLIBCXX_3.4.11 (Which is still missing anything to do with condition_variable_any, but given that my native 4.8 compiler doesn't contain this symbol either and my code builds and runs natively, I assume this is how it should be). Here is my build's version information: $ arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/mark/arm-linux-gnueabi-4.8.2/libexec/gcc/arm-linux-gnueabi/4.8.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../gcc-linaro-4.8-2013.10/configure --target=arm-linux-gnueabi --prefix=/home/mark/arm-linux-gnueabi-4.8.2 --with-local-prefix=/home/mark/arm-linux-gnueabi-4.8.2 --disable-nls --enable-shared --enable-multilib --disable-decimal-float --enable-languages=c,c++ --with-mpfr-include=/home/mark/gcc-4.8-arm-linux/gcc-build/../gcc-linaro-4.8-2013.10/mpfr/src --with-mpfr-lib=/home/mark/gcc-4.8-arm-linux/gcc-build/mpfr/src/.libs --enable-clocale=gnu --enable-threads=posix --enable-__cxa_atexit --disable-libstdcxx-pch --with-system-zlib --with-headers=/home/mark/arm-linux-gnueabi-4.8.2/include --with-libs=/home/mark/arm-linux-gnueabi-4.8.2/lib --enable-libstdcxx-threads --enable-libstdcxx-time Thread model: posix gcc version 4.8.2 20131014 (prerelease) (Linaro GCC 4.8-2013.10) I configured libstdc++-v3 respectively as follows: $ ../gcc-linaro-4.8-2013.10/libstdc++-v3/configure --host=arm-linux-gnueabi --prefix=/home/mark/arm-linux-gnueabi-4.8.2/ --enable-multilib --enable-shared --disable-nls --disable-libstdcxx-pch --enable-libstdcxx-threads --enable-libstdcxx-time I assumed the relevant entries to enable C++11 threading and condition variables etc would have been --enable-libstdcxx-threads --enable-libstdcxx-time. I must be missing some other options or have done something else wrong. Any suggestions? thanks, Mark

11 years, 11 months

[ACTIVITY] Week 47

by Renato Golin

== Progress == * Short week - Two days off due to a messy implant bloating my face - Should be better on Monday * Cambridge LLVM Day, Cambridge University Computer Lab - Presented the status of the auto-vectorizer in LLVM * Releasing candidate 1 of LLVM 3.4 - All tests green, running benchmarks - http://people.linaro.org/~rengolin/llvm/ * Buildbots - Adding Chromebook self-hosting (fixing MCJIT tests) - Adding Chromebook test-suite (fixing ClamAV) - Will turn off the old Chromebook and re-install it for benchmarks - Will add an Odroid XU in pair with the community one to be added next week * Background - Patch reviews, discussions * EEMBC rgbcmy implementation requires extensive changes to the compiler - Will deal with them on the background over the next months - While checking other EEMBC problems == Plan == * Continue the 3.4 release * Look at vectorization pragmas * Look at other EEMBC results

11 years, 11 months

[ACTIVITY] Week 47

by Will Newton

== Progress == * Committed a couple of gdb patches * Debug malloc to a working state, performance improved * First version of glibc aarch64 ifunc support * Found a couple of bugs in binutils aarch64 ifunc support == Issues == * Missed two days due to illness * Power cut and broadband outage on Wednesday afternoon == Plan == * Respin and submit glibc docs patches * Submit glibc aarch64 ifunc code -- Will Newton Toolchain Working Group, Linaro

11 years, 11 months

Is there any description about the toolchain release file naming rule?

by YongQin Liu

Hi, All Under this site http://releases.linaro.org/13.09/components/toolchain/binaries/, there are many files released. but do we have any description on the file naming rules? Sorry for my simple question, I just want to know what the files are used for. which one I should select when I need to use toolchain. Like the files below, I can guess that aarch64 means that it will generate files run on aarch64 platform, but I can not guess what's the difference between linux and none, and not know what's the difference between gnu and elf. So if you have any wiki/link about the the naming rules or description about the file, please share me. crosstool-ng-linaro-1.13.1-4.8-2013.09-01.tar.bz2 crosstool-ng-linaro-1.13.1-4.8-2013.09.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_runtime.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_src.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64-linux-gnu-4.8-2013.09-20130912_win32.exe gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64-linux-gnu-4.8-2013.09_runtime.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09_src.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip.xz gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_runtime.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_runtime.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_src.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip.xz gcc-linaro-arm-linux-gnueabihf-4.8-2013.09-20130912_win32.exe gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.bz2 gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.xz gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2 gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_src.tar.bz2 gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip.xz gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.bz2 gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.xz gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2 gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip.xz -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/pipermail/linaro-validation

11 years, 11 months

CortexM toolchain recommendations

by Trevor Woerner

Hi toolchain gurus, I am about to start some projects working with CortexMx devices and am wondering if anyone has an opinion on which toolchain(s) I should use/investigate? Being a fan of Linaro, my first instinct would be to use cbuild2 to build an arm-none-eabi- toolchain from a 4.8.x tree. But looking around I can't help notice https://launchpad.net/gcc-arm-embedded. Does anyone know if gcc-arm-embedded has things the Linaro toolchain doesn't wrt Cortex M0, M3, and M4 device/instruction support? Best regards, Trevor

11 years, 11 months

Fwd: [Bug target/59216] [ARM] negdi*extendsidi regression

by Christophe Lyon

-------- Original Message -------- Subject: [Bug target/59216] [ARM] negdi*extendsidi regression Date: Wed, 20 Nov 2013 18:06:14 +0100 From: christophe.lyon at st dot com <gcc-bugzilla(a)gcc.gnu.org> To: Christophe LYON <christophe.lyon(a)st.com> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59216 --- Comment #2 from christophe.lyon at st dot com --- Basically, the working code does: asrs r3, r2, #31 negs r2, r2 sbc.w r3, r3, r3, lsl #1 while the failing one does: negs r2, r2 asrs r3, r2, #31 -- You are receiving this mail because: You reported the bug.

11 years, 11 months

Testing Android on LAVA

by Renato Golin

Hi LAVA folks, I don't know if you guys know, but Android is moving to LLVM for the next release or so. As such, we'll need to do a lot of testing between now and next release to make sure each component can be compiled (and runs correctly) with LLVM on an incremental basis. We're trying to come up with a way for remotely testing the Linux kernel booting on ARM devices, more specifically an Android stack, and I'm finding it hard to do that with my home equipment. Doing that in LAVA would be ideal, and I know the Android team does it already, but our constraints could be a little different. Basically, there are two fronts: 1. Building Android components with LLVM, using a GCC-compiled kernel booting on an ARM board, in LAVA. This is something we should work internally on how to do it, and it'll be between Android, LAVA and Toolchain groups. 2. Building the Linux kernel with LLVM, and using a GCC-compiled image (like stock CyanogenMod) to test the kernel. We don't have such a kernel (many patches), but the LLVMLinux guys do, and that's where they come in. On the second case, the topic of this email, we'd have to liaise with them to fire jobs at LAVA from their own infrastructure (originally, manually only), and that might need some thinking. But ultimatelly, we want to have those jobs running on LAVA, so that later on we'd be able to have a third layer: Linux+Android built with LLVM with the same system level tests. Since the LLVMLinux guys don't have access to much ARM hardware, and since it's easier for us to scale (or to re-define) hardware requirements, having them running on LAVA makes even more sense. Is this something we can do? Is this being done already? Is this just a question of legal/corporate decision, or is there any technical issues we have to look into? Android folks, It might make more sense if you guys just grab their kernel and build the Android system based on that internally, so that we don't need external access to job submissions in LAVA, but that would mean work from you guys to patch it up, and that might not be in the roadmap for the next months. Is that a feasible route? cheers, --renato

11 years, 11 months

[ANNOUNCE] Linaro GCC 4.7 and 4.8 2013.11 released

by Christophe Lyon

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.8 and Linaro GCC 4.7. Linaro GCC 4.7 2013.11 is the twentieth release in the 4.7 series. Based off the latest GCC 4.7.4+svn204656 release, this is the seventh release after entering maintenance. Interesting changes include: * Updates to GCC 4.7.4+svn204656 Linaro GCC 4.8 2013.11 is the eighth release in the 4.8 series. Based off the latest GCC 4.8.2+svn204657 release, it includes performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.8.2+svn204657 * Fixes for bugs LP #1243656, #1243022 * Backport fix for PR/58423 * AArch64: added support for tiny model GOT access. * Improved Aarch32 A-profile multilibs support (--with-multilib-list option) The source tarballs are available from: http://releases.linaro.org/13.11/components/toolchain/gcc-linaro/4.7 http://releases.linaro.org/13.11/components/toolchain/gcc-linaro/4.8 Downloads are available from the Linaro GCC page on Launchpad: http://www.linaro.org/downloads/ More information on the features and issues are available from the release pages: https://launchpad.net/gcc-linaro/4.7/4.7-2013.11 https://launchpad.net/gcc-linaro/4.8/4.8-2013.11 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at support(a)linaro.org

11 years, 11 months

[Activity] Nov 10-16

by Rob Savoye

= Progress == * Created Cards for the infrastructure Team TODO list. * Finished Cbuildv2 support for building GDB binary tarballs. * Got Arch linux up on Odroid XU board again, seems stable, did a build and test run. * Experimented with lava-tool. * Tried to get GCC trunk building native on aarch64 for libsanitizer patch testing. * Upgraded gmp to 5.1.3 in infrastructure/ to work around a configure bug triggered by crouton native builds on a chromebook. * Setup chromebook slaves in new toolchain build farm. * Started adding support to Cbuildv2 to handle git URLs with a user name, ie.. git(a)staging.git.linaro.org to work around git repo problem. == Plan == * Finish support for user names in URLs. * Continue on remote testing support. * Keep trying gcc trunk on aarch64 native. * Fix git repo. == Issues == * GCC git repo hasn't been auto updating the svn branch of linaro-4.8-branch. It used to work... updating manually is now broken as well. * Somehow qemu snapshots tarballs are overwriting the toolchain directories on snapshots.linaro.org. * I don't think lava-tool is going to be useable for toolchain testing, as it only queues up an executable test case to be run later, whereas GCC expects the test to get run right away.

11 years, 11 months

[ACTIVITY] 12-15 November 2013

by Christophe Lyon

One day off == Progress == * Prepared 4.7 and 4.8 2013.11 releases. Some delay because of board crashes and disk full issues. * Aarch64: committed 'frame grows downward' patch. This removes a dependency for libsanitizer and libssp. * libsanitizer on Aarch64: blocked by GCC trunk not bootstrapping currently on Aarch64 HW (reported by Rob) * Looked at cross-build failures of trunk after new -fisolate-erroneous-paths. Ramana pointed me to Marcus' glibc patch, and I could switch my builds from eglibc to glibc. * cross-validations: updated list of configurations built&tested after discussion with Richard during Connect. == Next == * Announce 4.7 and 4.8 2013.11 releases * Continue investigating 'extended neg' fix (aka tar regression) * Look for patches to fix AArch64 bootstrap, so that we can test libsanitizer

11 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain