ADT_installer location: http://autobuilder.yoctoproject.org/pub/releases/dylan-1.4.2.rc1/adt-installer-QA/ ADT repo: http://adtrepo-dev.yoctoproject.org/1.4.2-d734ab491a30078d43dee5440c03acce2d251425-dylan/ Toolchain location: http://autobuilder.yoctoproject.org/pub/releases/dylan-1.4.2.rc1/toolchain/ Git rev: dylan/d734ab491a30078d43dee5440c03acce2d251425 This issue is same with bug 4783 and bug 4618 in Yocto 1.5. Steps: 1. Download adt_installer.tar.bz2 2. Setup the target architecture to arm and install the ADT. 3. After installation finish, I found the environment setting script is environment-setup-armv7a-vfp-neon-poky-linux-gnueabi. It should be environment-setup-armv5te-poky-linux-gnueabi. This file is from package meta-environment-arm_1.0-r8_x86_64-nativesdk.ipk in adt repo. For the arm toolchain tarball, this issue also exists. The cause is: On autobuilder, besides nightly-arm (qemuarm), there is an extra layers nightly-fsl-arm (imx53qsb) also build meta-toolchain and the ipk packages also be copied to adt repo. Although they have the same arch, the core cpu of target machine is different. Unfortunately, when generate the meta-environment-arm package, they have the same package name. So when copy the package to adt repo, the latest one will cover the previous one. For the end users, if they build the toolchain by themselves, this issue doesn't impact anything. But if they download the toolchain from the autobuilder or install adt via adt repo. It maybe make them confused. Do we need to regenerate the toolchain and adt repo for arm ?
Although the the script name is changed, the functions of adt and toolchain are good. All current test cases can pass. But I don't know if there is any potential issue.
(In reply to comment #1) > Although the the script name is changed, the functions of adt and toolchain > are good. All current test cases can pass. But I don't know if there is any > potential issue. I'm sorry that I made a mistake. Actually some test cases failed to run. Steps: 1. Download the arm toolchain tarball from http://autobuilder.yoctoproject.org/pub/releases/dylan-1.4.2.rc1/toolchain/ 2. Install the toolchain and set the environment. 3. Build C and C++ test programs with the cross-compiler: $ ${CC} ${CFLAGS} test.c -o testc -lm ${CXX} ${CXXFLAGS} testplus.cpp -o testcpp $ file testc testc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x420108aec85f7446771ad7eee04dbe5d806ea81d, not stripped $ file testcpp testcpp: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0xf1c71a40f6863b40344714a761750fdc3eeb68c4, not stripped These test programs can run in host with qemu-arm: $ qemu-arm -L /opt/poky/1.4.2/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/ ./testc convert: 10 => 10.000000 floorf(1234.670000) = 1234.000000 $ qemu-arm -L /opt/poky/1.4.2/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/ ./testcpp convert: 10 => 10.000000 floorf(1234.670000) = 1234.000000 4. Startup a qemuarm image and copy the above programs to the target. These 2 programs can *not* run: root@qemuarm:~# root@qemuarm:~# ./testc Illegal instruction root@qemuarm:~# root@qemuarm:~# ./testcpp Illegal instruction root@qemuarm:~# root@qemuarm:~# file testc testc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=ae08014246745fc8eed71a775dbe4de01da86e80, not stripped root@qemuarm:~# file testcpp testcpp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=401ac7f1403b86f6a7144734dc0f7561c468eb3e, not stripped root@qemuarm:~# When use adt-installer to cross compile these programs, this issue also happens. I attached my C & C++ test file.
Created attachment 1438 [details] test.c
Created attachment 1439 [details] testplus.cpp
Hi Yi, We won't fix this for 1.4.2. We'll release note this by asking user not using adt-installer but instead build their own toolchain using meta data to avoid the package override issue. But please can you verify the same testcase against 1.5 to make sure the problem is not there. If it exists in 1.5, we need to fix there. Thanks, Jessica
*** Bug 6346 has been marked as a duplicate of this bug. ***