[yocto] Yocto SDK generated - unable to compile application
Bas Mevissen
abuse at basmevissen.nl
Fri Sep 21 06:43:53 PDT 2018
On 2018-09-21 14:34, Evan O'Loughlin wrote:
> ________________________________________
> From: Bas Mevissen [abuse at basmevissen.nl]
> Sent: 20 September 2018 23:21
> To: Evan O'Loughlin
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] Yocto SDK generated - unable to compile
> application
>
> On 9/20/18 3:32 PM, Evan O'Loughlin wrote:
>>
>> ________________________________________
>> From: Bas Mevissen [abuse at basmevissen.nl]
>> Sent: 20 September 2018 13:23
>> To: Evan O'Loughlin
>> Cc: yocto at yoctoproject.org
>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>> application
>>
>> On 2018-09-20 12:28, Evan O'Loughlin wrote:
>>> ________________________________________
>>> From: Bas Mevissen [abuse at basmevissen.nl]
>>> Sent: 20 September 2018 10:50
>>> To: Evan O'Loughlin
>>> Cc: yocto at yoctoproject.org
>>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>>> application
>>>
>>> On 2018-09-20 11:40, Evan O'Loughlin wrote:
>>>> -----Original Message-----
>>>> From: Bas Mevissen [mailto:abuse at basmevissen.nl]
>>>> Sent: 20 September 2018 10:12
>>>> To: Evan O'Loughlin <evan.oloughlin at vitalograph.ie>
>>>> Cc: yocto at yoctoproject.org
>>>> Subject: Re: [yocto] Yocto SDK generated - unable to compile
>>>> application
>>>>
>>>> On 2018-09-20 10:08, Evan O'Loughlin wrote:
>>>>> Hello,
>>>>>
>>>>> I’m having an issue when I try to use the SDK generated by my yocto
>>>>> instance.
>>>>> Currently I have yocto set-up to correctly build my image – this
>>>>> all
>>>>> works well.
>>>>>
>>>>> I've built the SDK in the following ways:
>>>>> * bitbake {image} –c populate_sdk
>>>>> * bitbake meta-toolchain-qt5
>>>>> * bitbake {image-sdk} using a separate recipe with the options:
>>>>> - require {image}.bb
>>>>> - IMAGE_FEATURES += " dev-pkgs tools-sdk tools-debug
>>>>> eclipse-debug debug-tweaks"
>>>>> - IMAGE_INSTALL += "kernel-devsrc"
>>>>> - inherit populate_sdk populate_sdk_qt5
>>>>>
>>>>>
>>>>> When I try to use the generated SDKs I get the error below:
>>>>> Simple helloworld app:
>>>>> #include <stdio.h>
>>>>> #include <stdlib.h>
>>>>> #include <stddef.h>
>>>>> #include <cstddef>
>>>>>
>>>>> int main (int argc, char** argv)
>>>>> {
>>>>> printf("Hello World\n");
>>>>> return 0;
>>>>> }
>>>>>
>>>>> Compile error:
>>>>> ${CC} helloworld.c
>>>>> helloworld.c:4:19: fatal error: cstddef: No such file or
>>>>> directory
>>>>> #include <cstddef>
>>>>> ^
>>>>> compilation terminated
>>>>>
>>>>>
>>>>> Have I missed a step in generating the SDK?
>>>>>
>>>>>
>>>>
>>>> No, your SDK looks fine. The solution is to just remove the line
>>>>
>>>> #include <cstddef>
>>>>
>>>> from your c sources or use the g++ compiler (called ${CXX) in
>>>> Makefile) to compile the source.
>>>>
>>>>> Regards,
>>>>> vitalEol
>>>
>>>> Hi Bas,
>>>>
>>>> I'm using the offending line in helloworld.c to highlight the issue
>>>> I'm
>>>> seeing.
>>>>
>>>> My main program is a Qt application where I see the same issue when
>>>> trying to build in QtCreator.
>>>>
>>>> My issue relates to the fact that several include files are not
>>>> readily available after 'sourcing' the environment setup.
>>>>
>>>> Do I need to adjust/include other recipes when building the SDK?
>>>>
>>>
>>> I might be wrong, but this looks like you are using the gcc compiler
>>> instead of the g++ one. See the second part of my answer.
>>>
>>> To check your environment, check in your sdk that the file cstddef
>>> exists somewhere in /usr/include. Example from a Fedora Linux system:
>>>
>>> $ find /usr/include -name cstddef
>>> /usr/include/c++/8/cstddef
>>>
>>> If I compile your example with "gcc" on that system, I get the same
>>> error. With "g++", is is fine. It automatically find the cstddef
>>> header
>>> file in the /usr/include/c++/8 directory.
>>>
>>> Hope this helps,
>>>
>>> (and please do not top post as that makes a mail thread unreadable)
>>>
>>> -- Bas.
>>>
>>>
>>>> Regards,
>>>> Evan
>>>>
>>>
>>> Hi Bas,
>>>
>>> Apologies for top-posting previously.
>>>
>>> using ${CC}, ${CPP} or ${CXX} all show the same error relating to not
>>> finding the required include
>>>
>>> cstddef is available in the cross-compiler toolchain:
>>> $ find . -name cstddef
>>> ./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/c++/6.2.1/cstddef
>>> ./sysroots/armv7ahf-neon-linux-gnueabi/usr/include/boost/compatibility/cpp_c_headers/cstddef
>>>
>>
>> That looks fine.
>>
>>> and is also available on my system:
>>> $ find /usr/include -name cstddef
>>> /usr/include/c++/5/cstddef
>>> /usr/include/c++/4.7/cstddef
>>> /usr/include/c++/4.8/cstddef
>>>
>>>
>>> ${CC} --version && ${CPP} --version && ${CXX} --version
>>> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>>> Copyright (C) 2016 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There
>>> is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
>>> arm-linux-gnueabihf-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>>> Copyright (C) 2016 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There
>>> is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
>>> arm-linux-gnueabihf-g++ (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>>> Copyright (C) 2016 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There
>>> is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
>>
>> I tried with an Freescale i.MX6 SDK for Sumo and that compiled fine
>> with
>> ${CXX}.
>>
>> It is a bit of guessing now. Maybe somewhat more information might
>> help:
>>
>> What version of Yocto are you using? What layers are included? What
>> machine?
>>
>> Are you sure this is the cross compiler belonging to the SDK?
>>
>> Did you maybe move the SDK install location and not adapt the
>> environment file?
>> Please check this with "echo ${SDKTARGETSYSROOT}" and "echo ${CXX}"
>>
>>
>>>
>>> Regards,
>>> Evan
>>
>>
>> I'm using the yocto setup from Ti related to their processor-sdk
>> v04.03.00.05
>> (http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/04_03_00_05/index_FDS.html
>> &
>> http://software-dl.ti.com/processor-sdk-linux/esd/docs/04_03_00_05/linux/Overview.html#processor-sdk-linux-building-the-sdk)
>> Build Configuration:
>> BB_VERSION = "1.32.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING = "Ubuntu-16.04"
>> TARGET_SYS = "arm-linux-gnueabi"
>> MACHINE = "XYZ-PROD"
>> DISTRO = "arago"
>> DISTRO_VERSION = "2017.12"
>> TUNE_FEATURES = "arm armv7a vfp thumb neon
>> callconvention-hard"
>> TARGET_FPU = "hard"
>> meta-processor-sdk = "HEAD:92db4d8023d88ab59fab2953e7447ec0bd5a6db1"
>> meta-ros = "HEAD:e2566402ab108a19634354a934788109422cf409"
>> meta-arago-distro
>> meta-arago-extras = "HEAD:5b2a44b0c4d989133bc13d59398fd10375d351bb"
>> meta-browser = "HEAD:26d50665e2f7223c5f4ad7481a8d2431e7cb55fb"
>> meta-openamp = "HEAD:8a214032bfb7e8124bc1485c70c69f7d60abb819"
>> meta-qt5 = "HEAD:2c9f0e4eb0e9097f6f872ec1e1d81768a8ab5f1b"
>> meta-networking
>> meta-ruby
>> meta-python
>> meta-oe
>> meta-gnome
>> meta-multimedia = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
>> meta-ti = "HEAD:3dc08477529b31ce887bb22a08201a843ded48f0"
>> meta-linaro-toolchain
>> meta-optee = "HEAD:d73e794c7e7ebb1cc5bf495a52a72b26fb118250"
>> meta = "HEAD:39fd8c129e2bff7f2f1649b7f6e036ccc50fd5d8"
>> meta-XYZ =
>> "sdk_04.03.00.05_dev:61ec90da8c798b357a343b92d1e41c403e0365d9"
>> workspace = "<unknown>:<unknown>"
>>
>> I'm using the same machine to build the image for my device & to
>> generate the SDK.
>> bitbake {image} -c populate_sdk results in
>> arago-2017.12-toolchain-2017.12.sh installer which i use to install to
>> ~/tiToolchain_SDKv4
>>
>> The environment file is as follows - all paths are correct &
>> accessible :
>> export
>> SDKTARGETSYSROOT=/home/micheal/tiToolchain_SDKv4/sysroots/armv7ahf-neon-linux-gnueabi
>> export
>> PATH=/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/sbin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/bin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/sbin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/../x86_64-arago-linux/bin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabi:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/arm-linux-uclibc:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/arm-linux-musl:$PATH
>> export
>> CCACHE_PATH=/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/../x86_64-arago-linux/bin:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/arm-linux-gnueabi:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/arm-linux-uclibc:/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/arm-linux-musl:$CCACHE_PATH
>> export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
>> export
>> PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
>> export
>> CONFIG_SITE=/home/micheal/tiToolchain_SDKv4/site-config-armv7ahf-neon-linux-gnueabi
>> export
>> OECORE_NATIVE_SYSROOT="/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux"
>> export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
>> export OECORE_ACLOCAL_OPTS="-I
>> /home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/share/aclocal"
>> unset command_not_found_handle
>> export CC="arm-linux-gnueabihf-gcc -march=armv7-a -marm -mfpu=neon
>> -mfloat-abi=hard --sysroot=$SDKTARGETSYSROOT"
>> export CXX="arm-linux-gnueabihf-g++ -march=armv7-a -marm -mfpu=neon
>> -mfloat-abi=hard --sysroot=$SDKTARGETSYSROOT"
>> export CPP="arm-linux-gnueabihf-gcc -E -march=armv7-a -marm
>> -mfpu=neon -mfloat-abi=hard --sysroot=$SDKTARGETSYSROOT"
>> export AS="arm-linux-gnueabihf-as "
>> export LD="arm-linux-gnueabihf-ld --sysroot=$SDKTARGETSYSROOT"
>> export GDB=arm-linux-gnueabihf-gdb
>> export STRIP=arm-linux-gnueabihf-strip
>> export RANLIB=arm-linux-gnueabihf-ranlib
>> export OBJCOPY=arm-linux-gnueabihf-objcopy
>> export OBJDUMP=arm-linux-gnueabihf-objdump
>> export AR=arm-linux-gnueabihf-ar
>> export NM=arm-linux-gnueabihf-nm
>> export M4=m4
>> export TARGET_PREFIX=arm-linux-gnueabihf-
>> export CONFIGURE_FLAGS="--target=arm-linux-gnueabi
>> --host=arm-linux-gnueabi --build=x86_64-linux
>> --with-libtool-sysroot=$SDKTARGETSYSROOT"
>> export CFLAGS="
>> -isystem/home/micheal/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include
>> -O2 -pipe -g -feliminate-unused-debug-types "
>> export CXXFLAGS="
>> -isystem/home/micheal/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include
>> -O2 -pipe -g -feliminate-unused-debug-types "
>> export LDFLAGS="
>> -L/home/micheal/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/lib
>> -Wl,-rpath-link,/home/micheal/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/lib
>> -Wl,-O1 -Wl,--hash-style=gnu"
>> export CPPFLAGS="
>> -isystem/home/micheal/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/include
>> "
>> export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
>> export OECORE_DISTRO_VERSION="2017.12"
>> export OECORE_SDK_VERSION="2017.12"
>> export ARCH=arm
>> export CROSS_COMPILE=arm-linux-gnueabihf-
>>
>> # Append environment subscripts
>> if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then
>> for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do
>> . $envfile
>> done
>> fi
>> if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then
>> for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do
>> . $envfile
>> done
>> fi
>>
>>
>>
>> echo ${SDKTARGETSYSROOT} && echo ${CXX}
>> /home/micheal/tiToolchain_SDKv4/sysroots/armv7ahf-neon-linux-gnueabi
>> arm-linux-gnueabihf-g++ -march=armv7-a -marm -mfpu=neon
>> -mfloat-abi=hard
>> --sysroot=/home/micheal/tiToolchain_SDKv4/sysroots/armv7ahf-neon-linux-gnueabi
>>
>>
>> Thanks for your help so far with this; I'm stumped as to why the
>> headers are not found.
>>
>
> I downloaded their toolchain from
> https://releases.linaro.org/components/toolchain/binaries/6.2-2016.11/arm-linux-gnueabihf/gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabihf.tar.xz
>
> This one seems fine:
>
> $ echo "#include <cstddef>" | ./bin/arm-linux-gnueabihf-cpp -E -x c++
> -o
> /dev/null -
>
> (also works with -cpp replaced by -gcc and -g++)
>
> To see how a failure looks like, replace -x c++ with -x c:
>
> $ echo "#include <cstddef>" | ./bin/arm-linux-gnueabihf-cpp -E -x c -o
> /dev/null -
> <stdin>:1:19: fatal error: cstddef: No such file or directory
> compilation terminated.
>
>
> So maybe simply overwrite the toolchain in your SDK with the one from
> the link above. That will get you started at least.
>
> Otherwise, use strace to see where it looks for the cstddef file:
>
> echo "#include <cstddef>" | strace -f ${CXX} -E -x c++ -o /dev/null -
> 2>&1 | grep cstddef
>
> Cheers,
>
> Bas.
>
>
>>
>> Regards,
>> Evan
>>
>>
>>
>
>
>
> $echo "#include <cstddef>" | strace -f ${CXX} -E -x c++ -o /dev/null -
> 2>&1 | grep cstddef
> [pid 24705] read(0, "#include <cstddef>\n", 8192) = 19
> [pid 24705]
> lstat("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/arm-linux-gnueabihf/include/c++/6.2.1/cstddef",
> {st_mode=S_IFREG|0644, st_size=1931, ...}) = 0
> [pid 24705]
> open("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/arm-linux-gnueabihf/include/c++/6.2.1/cstddef",
> O_RDONLY|O_NOCTTY) = 0
>
> /home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/arm-linux-gnueabihf/include/c++/6.2.1/cstddef:
> C source, ASCII text
>
> $echo "#include <cstddef>" | strace -f ${CXX} -E -x c -o /dev/null -
> 2>&1 | grep cstddef
> [pid 23570] read(0, "#include <cstddef>\n", 8192) = 19
> [pid 23570]
> lstat("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/lib/gcc/arm-linux-gnueabihf/6.2.1/include/cstddef",
> 0x7ffcd905d490) = -1 ENOENT (No such file or directory)
> [pid 23570]
> open("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.2.1/include/cstddef",
> O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
> [pid 23570]
> lstat("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/lib/gcc/arm-linux-gnueabihf/6.2.1/include-fixed/cstddef",
> 0x7ffcd905d490) = -1 ENOENT (No such file or directory)
> [pid 23570]
> open("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.2.1/include-fixed/cstddef",
> O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
> [pid 23570]
> lstat("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/arm-linux-gnueabihf/include/cstddef",
> 0x7ffcd905d490) = -1 ENOENT (No such file or directory)
> [pid 23570]
> open("/home/micheal/tiToolchain_SDKv4/sysroots/x86_64-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/6.2.1/../../../../arm-linux-gnueabihf/include/cstddef",
> O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
> [pid 23570]
> lstat("/home/micheal/tiToolchain_SDKv4/sysroots/armv7ahf-neon-linux-gnueabi/usr/include/cstddef",
> 0x7ffcd905d490) = -1 ENOENT (No such file or directory)
> [pid 23570]
> open("/home/micheal/tiToolchain_SDKv4/sysroots/armv7ahf-neon-linux-gnueabi/usr/include/cstddef",
> O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
> [pid 23570] write(2, "<stdin>:1:19: fatal error: cstdd"...,
> 62<stdin>:1:19: fatal error: cstddef: No such file or directory
>
>
> I've changed my paths in QtCreator to use 'arm-linux-gnueabihf-g++' by
> default which seems to find the correct headers.
>
I'm happy to hear you have something that works now.
Ah, now finally the penny drops (on my side):
${CC} helloworld.c will never work as gcc assumes C language and your
source is c++ due to the inclusion of <cstddef>.
One should write:
${CC} -x c++ helloworld.c # force c++
or
${CXX} helloworld.c # $CXX has c++ as default language
or
mv helloworld.c helloworld.cpp && ${CC} helloworld.cpp # Now gcc
understands from the file extension it is c++
File extentions .c++ or .C (note the capital C!) are fine too BTW.
The preprocessor ($CPP) will also understand the source correctly from
the extension or by using the -x c++ option.
Cheers,
Bas.
> Thanks for your help Bas.
>
> Regards,
> Evan
More information about the yocto
mailing list