* Yocto SDK generated - unable to compile application
@ 2018-09-20 8:08 Evan O'Loughlin
2018-09-20 9:11 ` Bas Mevissen
0 siblings, 1 reply; 10+ messages in thread
From: Evan O'Loughlin @ 2018-09-20 8:08 UTC (permalink / raw)
To: yocto
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?
Regards,
vitalEol
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Yocto SDK generated - unable to compile application 2018-09-20 8:08 Yocto SDK generated - unable to compile application Evan O'Loughlin @ 2018-09-20 9:11 ` Bas Mevissen 2018-09-20 9:40 ` Evan O'Loughlin 0 siblings, 1 reply; 10+ messages in thread From: Bas Mevissen @ 2018-09-20 9:11 UTC (permalink / raw) To: Evan O'Loughlin; +Cc: yocto 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 9:11 ` Bas Mevissen @ 2018-09-20 9:40 ` Evan O'Loughlin 2018-09-20 9:50 ` Bas Mevissen 0 siblings, 1 reply; 10+ messages in thread From: Evan O'Loughlin @ 2018-09-20 9:40 UTC (permalink / raw) To: 'Bas Mevissen'; +Cc: yocto 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? Regards, Evan -----Original Message----- From: Bas Mevissen [mailto:abuse@basmevissen.nl] Sent: 20 September 2018 10:12 To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> Cc: yocto@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 9:40 ` Evan O'Loughlin @ 2018-09-20 9:50 ` Bas Mevissen 2018-09-20 10:28 ` Evan O'Loughlin 0 siblings, 1 reply; 10+ messages in thread From: Bas Mevissen @ 2018-09-20 9:50 UTC (permalink / raw) To: Evan O'Loughlin; +Cc: yocto On 2018-09-20 11:40, Evan O'Loughlin wrote: > -----Original Message----- > From: Bas Mevissen [mailto:abuse@basmevissen.nl] > Sent: 20 September 2018 10:12 > To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> > Cc: yocto@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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 9:50 ` Bas Mevissen @ 2018-09-20 10:28 ` Evan O'Loughlin 2018-09-20 12:23 ` Bas Mevissen 0 siblings, 1 reply; 10+ messages in thread From: Evan O'Loughlin @ 2018-09-20 10:28 UTC (permalink / raw) To: Bas Mevissen; +Cc: yocto ________________________________________ From: Bas Mevissen [abuse@basmevissen.nl] Sent: 20 September 2018 10:50 To: Evan O'Loughlin Cc: yocto@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@basmevissen.nl] > Sent: 20 September 2018 10:12 > To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> > Cc: yocto@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 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. Regards, Evan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 10:28 ` Evan O'Loughlin @ 2018-09-20 12:23 ` Bas Mevissen 2018-09-20 13:32 ` Evan O'Loughlin 0 siblings, 1 reply; 10+ messages in thread From: Bas Mevissen @ 2018-09-20 12:23 UTC (permalink / raw) To: Evan O'Loughlin; +Cc: yocto On 2018-09-20 12:28, Evan O'Loughlin wrote: > ________________________________________ > From: Bas Mevissen [abuse@basmevissen.nl] > Sent: 20 September 2018 10:50 > To: Evan O'Loughlin > Cc: yocto@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@basmevissen.nl] >> Sent: 20 September 2018 10:12 >> To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> >> Cc: yocto@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 12:23 ` Bas Mevissen @ 2018-09-20 13:32 ` Evan O'Loughlin 2018-09-20 22:21 ` Bas Mevissen 0 siblings, 1 reply; 10+ messages in thread From: Evan O'Loughlin @ 2018-09-20 13:32 UTC (permalink / raw) To: Bas Mevissen; +Cc: yocto ________________________________________ From: Bas Mevissen [abuse@basmevissen.nl] Sent: 20 September 2018 13:23 To: Evan O'Loughlin Cc: yocto@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@basmevissen.nl] > Sent: 20 September 2018 10:50 > To: Evan O'Loughlin > Cc: yocto@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@basmevissen.nl] >> Sent: 20 September 2018 10:12 >> To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> >> Cc: yocto@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. Regards, Evan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 13:32 ` Evan O'Loughlin @ 2018-09-20 22:21 ` Bas Mevissen 2018-09-21 12:34 ` Evan O'Loughlin 0 siblings, 1 reply; 10+ messages in thread From: Bas Mevissen @ 2018-09-20 22:21 UTC (permalink / raw) To: Evan O'Loughlin; +Cc: yocto On 9/20/18 3:32 PM, Evan O'Loughlin wrote: > > ________________________________________ > From: Bas Mevissen [abuse@basmevissen.nl] > Sent: 20 September 2018 13:23 > To: Evan O'Loughlin > Cc: yocto@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@basmevissen.nl] >> Sent: 20 September 2018 10:50 >> To: Evan O'Loughlin >> Cc: yocto@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@basmevissen.nl] >>> Sent: 20 September 2018 10:12 >>> To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> >>> Cc: yocto@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 > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-20 22:21 ` Bas Mevissen @ 2018-09-21 12:34 ` Evan O'Loughlin 2018-09-21 13:43 ` Bas Mevissen 0 siblings, 1 reply; 10+ messages in thread From: Evan O'Loughlin @ 2018-09-21 12:34 UTC (permalink / raw) To: Bas Mevissen; +Cc: yocto ________________________________________ From: Bas Mevissen [abuse@basmevissen.nl] Sent: 20 September 2018 23:21 To: Evan O'Loughlin Cc: yocto@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@basmevissen.nl] > Sent: 20 September 2018 13:23 > To: Evan O'Loughlin > Cc: yocto@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@basmevissen.nl] >> Sent: 20 September 2018 10:50 >> To: Evan O'Loughlin >> Cc: yocto@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@basmevissen.nl] >>> Sent: 20 September 2018 10:12 >>> To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> >>> Cc: yocto@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. Thanks for your help Bas. Regards, Evan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Yocto SDK generated - unable to compile application 2018-09-21 12:34 ` Evan O'Loughlin @ 2018-09-21 13:43 ` Bas Mevissen 0 siblings, 0 replies; 10+ messages in thread From: Bas Mevissen @ 2018-09-21 13:43 UTC (permalink / raw) To: Evan O'Loughlin; +Cc: yocto On 2018-09-21 14:34, Evan O'Loughlin wrote: > ________________________________________ > From: Bas Mevissen [abuse@basmevissen.nl] > Sent: 20 September 2018 23:21 > To: Evan O'Loughlin > Cc: yocto@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@basmevissen.nl] >> Sent: 20 September 2018 13:23 >> To: Evan O'Loughlin >> Cc: yocto@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@basmevissen.nl] >>> Sent: 20 September 2018 10:50 >>> To: Evan O'Loughlin >>> Cc: yocto@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@basmevissen.nl] >>>> Sent: 20 September 2018 10:12 >>>> To: Evan O'Loughlin <evan.oloughlin@vitalograph.ie> >>>> Cc: yocto@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2018-09-21 13:44 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-20 8:08 Yocto SDK generated - unable to compile application Evan O'Loughlin 2018-09-20 9:11 ` Bas Mevissen 2018-09-20 9:40 ` Evan O'Loughlin 2018-09-20 9:50 ` Bas Mevissen 2018-09-20 10:28 ` Evan O'Loughlin 2018-09-20 12:23 ` Bas Mevissen 2018-09-20 13:32 ` Evan O'Loughlin 2018-09-20 22:21 ` Bas Mevissen 2018-09-21 12:34 ` Evan O'Loughlin 2018-09-21 13:43 ` Bas Mevissen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.