linaro-toolchain

linaro-toolchain@lists.linaro.org

2 participants
5790 discussions

gcc-linaro-6.1-2016.07...Big Endian and Little Endian aarch64 Options

by stimits＠comcast.net

Hi, I was able to get linaro-6.1-2016.07 compiled for both aarch64 and armhf. I also have some prebuilt 5.2 and 5.3 binaries, plus a few other 4.8 and 4.9 compilers from quite some time back. I've used these for building a Linux 3.10 kernel, and the newer linaro-6.1 fails during kernel compile. The issue seems to be the assembler does not recognize option "-EL" (all of the ARM systems I'm building for are little endian, I've not seen a big endian system). I am wondering if support for options "-EB" and "-EL" are part of the configure options? There is the generic "help" listing the "--enable-FEATURE=ARG", but I do not see a comprehensive list of features this might deal with. I'm hoping that big/little endian for armhf and aarch64 can be enabled with this. Otherwise I'm hoping to find more information on what I might need to do or change for compatibility with the "-EL" option. For reference, I have similar templates for 32-bit and 64-bit configuration (different triplet and build root). Here's one: export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export BUILD='/home/build/linaro/32bit'export TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf cd $BUILD${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/ Thanks!

10 years

gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question

by stimits＠comcast.net

Hi, In a previous thread some sysroot issues were resolved, and I am able to build cross-compilers under gcc-linaro-snapshot-6.1-2016.07 for languages c, c++, and objc. My sysroot consisted of a loopback mounted dd copy of an Ubuntu 14.04 file system for aarch64. That particular file system runs on a quad core Cortex-A57, and is fully capable of compiling many different types of software (the file system is set up for development). The successful configuration was like this (configuration and compile was from an independent directory not in the source tree): export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export TRIPLET=aarch64-linux-gnuexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=arm64 ${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c,c++,objc \ --with-sysroot=/ Now I also need armhf (I must support both 32-bit and 64-bit), so I'm trying to figure out host and sysroot differences (I have been unable to get armhf to compile). The configuration is basically this variation of the above, plus some sysroot additional support: export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf ${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/ Note that for testing purposes I tried to compile only languages of c, c++, and objc, each one at a time instead of together. Errors do not differ in any way for picking of any of those three languages. I also have a complete Ubuntu 14.04 file system for armhf which is fully equipped for building of each of those languages, and is perhaps in some ways more complete as a development environment than the previously successful aarch64 file system (the sysroot runs on a quad core Cortex-A15). I tried this purely armhf file system as the sysroot to rule out incorrect multiarch support, and the error did not change. I am guessing the issue is not the sysroot, but I wanted to verify this since there may be other requirements for armhf instead of aarch64. I am at a loss though to explain why the host would be at issue since it appears all prerequisites were met and I had success with aarch64. The details of the error seem to always occur in libcc1 build. I see this in the libcc1/config.log as the failure regardless of sysroot or supported language, and only while building for armhf: configure:14569: checking for -rdynamicconfigure:14579: result: yesconfigure:14589: checking for library containing dlopenconfigure:14620: gcc -o conftest -g -O2 conftest.c >&5/tmp/ccyhVkpp.o: In function `main':/home/build/linaro/objdir/libcc1/conftest.c:38: undefined reference to `dlopen'collect2: error: ld returned 1 exit statusconfigure:14620: $? = 1configure: failed program was:| /* confdefs.h */| #define PACKAGE_NAME "libcc1"| #define PACKAGE_TARNAME "libcc1"| #define PACKAGE_VERSION "version-unused"| #define PACKAGE_STRING "libcc1 version-unused"| #define PACKAGE_BUGREPORT ""| #define PACKAGE_URL ""| #define STDC_HEADERS 1| #define HAVE_SYS_TYPES_H 1| #define HAVE_SYS_STAT_H 1| #define HAVE_STDLIB_H 1| #define HAVE_STRING_H 1| #define HAVE_MEMORY_H 1| #define HAVE_STRINGS_H 1| #define HAVE_INTTYPES_H 1| #define HAVE_STDINT_H 1| #define HAVE_UNISTD_H 1| #define __EXTENSIONS__ 1| #define _ALL_SOURCE 1| #define _GNU_SOURCE 1| #define _POSIX_PTHREAD_SEMANTICS 1| #define _TANDEM_SOURCE 1| #define HAVE_DLFCN_H 1| #define LT_OBJDIR ".libs/"| #define HAVE_DECL_BASENAME 1| /* end confdefs.h. */ Are there different host requirements when building armhf versus aarch64 which might explain why dlopen is not found? FYI, both development and other support for dlopen exists already on the system, so the failure to find dlopen is not for lack of host support (related dlopen files all seem to be present on all tested sysroots as well, both as armhf and aarch64). Is this a sysroot issue, a host issue, or a configure issue? Thanks!

10 years

[ACTIVITY] Week 32

by Yvan Roux

== Progress == o Linaro GCC/Validation (3/10) - Backports: tracking missing dependencies. - Looked at our AArch64 builder issues, reproduced the problem. o Upstream GCC (3/10) - Found a fix for guality tests failures, analyzing all the test case which can be impacted. o Misc (4/10) * Various meetings and discussions. * Internal support on GCC == Plan == o Continue on backports, and FSF branch merge o Finalize and submit on-going patches

10 years

stdc-predef.h failed during gcc-linaro-snapshot-6.1-2016.07 compile

by stimits＠comcast.net

Hi, I've been trying to build the c and c++ cross-compiler for triplet aarch64-linux-gnu (--target=aarch64-linux-gnu --enable-languages=c,c++) on snapshot for 6.1-2016.07, and cannot get past this: cc1: error: no include path in which to search for stdc-predef.h From what I can tell this may already be a known bug inherited from back in the days of Linaro 4.8. I tried various ways around this, such as trying to create an empty stdc-predef.h in various locations, but always ended up either not fixing the issue or breaking something else even sooner. Is there a simple way around this on the configure command line? If not, is there some recommended edit for this? Thanks!

10 years

[ANNOUNCE] Linaro Binary Toolchain Release-Candidate GCC 6.1-2016.08-rc1

by Ryan Arnold

The Linaro Binary Toolchain ============================ The Linaro GCC 6.1-2016.08-rc1 Release-Candidate is now available. Download release-candidate packages from: http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.08-rc1/ http://snapshots.linaro.org/components/toolchain/binaries/6.1-2016.08-rc1/ Previous snapshots and release-candidates are at: http://snapshots.linaro.org/components/toolchain/binaries/ Previous releases are at: http://releases.linaro.org/components/toolchain/binaries/ Host Requirements ================== Linaro officially supports the current and previous Ubuntu LTS releases (as of the time of this release). This does not mean that the toolchain will not work on other/older Linux distributions. See the following for the life-time of Ubuntu LTS releases. https://wiki.ubuntu.com/Releases The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc's memcpy API. https://bugs.linaro.org/show_bug.cgi?id=1869 Package Versions ================= Linaro GCC 6.1-2016.08-rc1 FSF glibc 2.23 (linaro/2.23) Linaro newlib 2.4.0-2016.03 (linaro-2.4-branch) Linaro binutils 2.26 (linaro_binutils-2_26-branch) FSF GDB 7.11 (binutils-gdb.git~gdb-7.11-branch) Linaro toolchain package git branches are hosted at: http://git.linaro.org/?a=project_list&s=toolchain%2F&btnS=Search NEWS for Linaro GCC 6.1-2016.08-rc1 ==================================== * Performance related backports from Linaro GCC 6.1-2016.06, and Linaro GCC 6.1-2016.07 have been included. See the following Linaro GCC snapshots: http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.06/ http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.1-2016.07/ Contact Linaro =============== File bugs at http://bugs.linaro.org For Linaro member support see http://support.linaro.org For Linaro community support email linaro-toolchain(a)lists.linaro.org -- Ryan S. Arnold | Linaro Toolchain Engineering Manager ryan.arnold(a)linaro.org | ryanarn on #linaro-tcwg @ freenode.irc.net

10 years

[ACTIVITY] 8 - 12 August 2016

by Diana Picus

== Progress == * Refactor SelectionDAGBuilder::visitInlineAsm [TCWG-643] [1/10] - Incorporated some review feedback and committed the patch upstream * [AArch64] Support for label arithmetic in the assembler [TCWG-710] [4/10] - Most of the support seems to be there, but the error checking is too aggressive and it rejects cases that could in fact be handled by the assembler - Trying to figure out exactly what the assembler can currently handle and how to relax the error checking accordingly * [AArch64] Keep merging consecutive stores in store sequences [TCWG-704] [2/10] - Fixing this might slow down the compiler more than the optimization is worth - Got some debug dumps on the test-suite to see how often sequences of consecutive stores show up * Misc [3/10] - Booked trip to Cambridge / Hebden Bridge - Buildbot babysitting (2 nasty selfhost failures), code reviews, LLVM Cauldron == Plan == * [AArch64] Support for label arithmetic in the assembler [TCWG-710] * [AArch64] Keep merging consecutive stores in store sequences [TCWG-704]

10 years

[ACTIVITY] 8-12 August 2016

by Yao Qi

# Progress # * TCWG-685, GDB 7.12 release. [4/10] Triaged all aarch64 native test results. Two patches fixing heap overflow are posted. The new C++11 ABI tag makes troubles to some gdb.cp tests. Rebuild armhf toolchain for GDB arm native test. glibc failed to build due to "gperf" is not found. * AArch64 OpenOCD investigation. Done. [2/10] Write a report. In general, there was a patch for AArch64 OpenOCD, but some issues should be addressed before it can be merged to mainline. * Interview in US Embassy, and file expense. [2/10] * Misc, meetings, [2/10] # Plan # * TCWG-685, GDB 7.12 release. Build recent native armhf toolchain, and test gdb 7.12 with it. Bug fixes if needed. * Off on Wed and Thu. -- Yao Qi

10 years

[ACTIVITY] 8-12 August 2016

by Prathamesh Kulkarni

== This Week == * LTO (6/10) a) TCWG-666 (5/10) - Patch iterations based on suggestions from Honza and Martin - Honza approved patch, however I see some failures during bootstrap+test, submitted patch to address those. b) TCWG-548 (1/10) - Benchmarking SPEC2006 on my chromebook cancelled midway due to issues with chromebook. - Setting up hacking session on juno-01 with help from Maxim - Analyzing SPEC2k results. * TCWG-72 (1/10) - Submitted patch upstream to set NULL for sdivmod_optab entry in optabs.def * Bugs (2/10) - Committed fix for fallouts caused by previous patches - TCWG-700: Patch iterations based on upstream discussion * Misc (1/10) - Meetings == Next Week == - Holidays

10 years

Impact of binutils .align assembler directive parsing bug

by Dan Handley

Hi I have a question about the impact of a binutils bug to do with parsing the .align assembler directive, which may appear soon in a Linaro GCC release. The bug was first discovered by Jérôme Forissier when building ARM Trusted Firmware with a non-Linaro toolchain: https://lists.linaro.org/pipermail/linaro-toolchain/2016-June/005768.html As Jim Wilson helpfully noted later in that thread: > This patch isn't present in the binutils-2.25 that tcwg is using. The patch is present in binutils-2.26. The bug is now fixed in binutils mainline: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7ea12e5… But this was too late to be in the binutils-2_27 tag (3rd August) I'm concerned that this bug may appear in the upcoming Linaro GCC 6 stable release, which may have a significant lifetime. Can anyone comment on the binutils version to be used in the Linaro GCC 6 release? If a binutils version containing the bug is used, is it possible for this to be patched with the fix? I need to know whether we need to provide an interim solution in ARM Trusted Firmware. Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

10 years

A stable version of gcc-linaro-xxx-arm-linux-gnueabi ...

by darklight wu

Hello linaro experts! I'm using the stable version(gcc-linaro-4.9-2014.11) recommended on https://wiki.linaro.org/WorkingGroups/ToolChain. I downloaded the binary fromhttps://releases.linaro.org/14.11/components/toolchain/binaries/arm-lin…. But I found there is no libstdc++.so.6. Is that library missing in that version? What I need is just a tested stable version for an industry iot project and the stability is the most important thing. And due to app back-compatibility, I can not use hardware-float feature. So any recommendation for a tested stable version of _gcc-linaro-xxx-arm-linux-gnueabi_ toolchain? Thanks! dlw

10 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain