This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/PROCESSOR-SDK-AM335X: Arago build error: libtool-cross configuration failed

Part Number: PROCESSOR-SDK-AM335X

Tool/software: Linux

Hello I'am trying to build arago-base-tisdk-image using this steps (checked from scratch multiple times):

# Host - Ubuntu 16.04 - 64 bit
sudo apt-get install git build-essential python diffstat texinfo gawk chrpath dos2unix wget unzip socat doxygen libc6:i386 libncurses5:i386 libstdc++6:i386 libz1:i386
sudo dpkg-reconfigure dash
# say NO

wget https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11/arm-linux-gnueabihf/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz 
tar -Jxvf gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz -C $HOME
wget https://releases.linaro.org/components/toolchain/binaries/7.2-2017.11/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz
tar -Jxvf gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz -C $HOME

git clone git://arago-project.org/git/projects/oe-layersetup.git tisdk
cd tisdk
./oe-layertool-setup.sh -f configs/processor-sdk/processor-sdk-05.02.00.10-config.txt
cd build
. conf/setenv
export TOOLCHAIN_PATH_ARMV7=$HOME/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf
export TOOLCHAIN_PATH_ARMV8=$HOME/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu
MACHINE=am335x-evm bitbake arago-base-tisdk-image

Build fails with message:

ERROR: libtool-cross-2.4.6-r0 do_configure: configure failed
ERROR: libtool-cross-2.4.6-r0 do_configure: Function failed: do_configure (log file is located at /home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0/temp/log.do_configure.6007)

File log.do_configure.6007:
...
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabihf-gcc -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard --sysroot=/home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0/recipe-sysroot
checking whether the C compiler works... no
configure: error: in `/home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0/build':
configure: error: C compiler cannot create executables
See `config.log' for more details
...

File config.log:

...
configure:3815: checking whether the C compiler works
configure:3837: arm-linux-gnueabihf-gcc -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard --sysroot=/home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0/recipe-sysroot -isystem/home/andrey/data/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0=/usr/src/debug/libtool-cross/2.4.6-r0 -fdebug-prefix-map=/home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0/recipe-sysroot-native= -fdebug-prefix-map=/home/andrey/data/tisdk/build/arago-tmp-external-linaro-toolchain/work/armv7ahf-neon-linux-gnueabi/libtool-cross/2.4.6-r0/recipe-sysroot= -isystem/home/andrey/data/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include -L/home/andrey/data/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/lib -Wl,-rpath-link,/home/andrey/data/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/lib -Wl,-O1 -Wl,--hash-style=gnu conftest.c >&5
/media/andrey/data/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find ../../lib/libc.so.6
...

So, configutaion fails because cross-compiler can't find libc.so.6. 
Indeed, libc.so.6 is broken symbolik line to libc-2.25.so (Look at screenshot)

In my previous builds on virtual machine this directory containde files lib<XXX>-2.25.so copied from cross-compiler dir:
gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc (Look at screenshot)

Why the cross compiler libs are missing? Thanks!

  • Hello Andrey,

    These files are getting included by external-linaro-toolchain.bbappend recipe, which means that your host computer's default terminal shell has not successfully changed to bash, or you have not closed the old terminal window and opened a new one after changing the default terminal to bash, or your bash terminal is broken. To fix this, please try to build on another freshly installed host machine.

    Best regards,
    Kemal

  • Hello Kemal,

    you're right. Indeed, the problem was related to some user settings (.bashrc, .profile or something else i'm not sure). Build passed without errors under the new user. Thank you very much! I hope life treats you kind and i hope you have all you've dreamed of.

  • Thanks Andrey. I wish you the same.
  • I know this is reported as resolved, but I encountered the same exact problem, and the suggested solution of dash vs. bash was definitely not applicable in my case.

    I believe the actual cause of the problem is when TMPDIR (in conf/local.conf) is a pathname that itself contains a symbol link as one of its components. This somehow interferes with the creation of the targets of the symbolic links in the sysroot lib directory.

    To see if this is the case, you can cd to TMPDIR and then type /bin/pwd. If this produces a different path than the value of TMPDIR, then the problem reported will occur.
  • Thank you for sharing your findings Rick. It for sure will be in help to someone who met the same or similar issue.
  • Hello, Rick Sladkey

    I can confirm that in my case, symbolic links also were present in the path TMPDIR. Because I placed the working directory on a separate disk and entered it through a symbolic link from the home directory. Later I always used absolute paths and no errors occurred.