[Buildroot] buildroot does not copy the C++ headers to sysroot

[Buildroot] buildroot does not copy the C++ headers to sysroot

[bart.thoelen at telenet.be]

Hi, 

I successfully have created myself a basic kernel image and rootfs using buildoot (2014.08). Im using the codesourcery arm-xilinx-linux toolchain (2013.05) as an external toochain. 

I'm trying to add a C++ (autotools-generated) project but this fails to compile with message "cc1plus: error: include location "/usr/include" is unsafe for cross-compilation [-Werror=poison-system-directories]". 
The project compiles perfectly when manually configured for the toochain (hence not using buildroot). 

After some debugging I found that the C++ headers have not copied from the external toolchain into the buildroot's output/host folder. The libs are there - very strangly. 

As a test I made a make clean, configured buildroot to use and download the codesourcery toolchain 2013.05m but still the same issue. 

What I'm doing wrong here ?? 

buildroot .confg and the projects .mk included. 

Many thanks. 

BartT 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141124/342bcf4c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nmcmdserver.mk
Type: text/x-makefile
Size: 516 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141124/342bcf4c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/octet-stream
Size: 43238 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20141124/342bcf4c/attachment.obj>

[Buildroot] buildroot does not copy the C++ headers to sysroot

[Peter Korsgaard]

>>>>> "bart" == bart thoelen <bart.thoelen@telenet.be> writes:

Hi,

 > Hi, 
 > I successfully have created myself a basic kernel image and rootfs
 > using buildoot (2014.08). Im using the codesourcery arm-xilinx-linux
 > toolchain (2013.05) as an external toochain.

Great! Your .config mentions a locally installed Xilinx toolchain
though.


 > I'm trying to add a C++ (autotools-generated) project but this fails
 > to compile with message "cc1plus: error: include location
 > "/usr/include" is unsafe for cross-compilation

That sounds wrong. You shouldn't be looking in /usr/include for your
cross-headers. How does the exact $cross-g++ invocation look like?


> [-Werror=poison-system-directories]".
 > The project compiles perfectly when manually configured for the toochain (hence not using buildroot). 

 > After some debugging I found that the C++ headers have not copied from
 > the external toolchain into the buildroot's output/host folder. The
 > libs are there - very strangly.

Are you sure you are looking in the correct location?
output/host/usr/include is the headers for host libraries. The headers
for the target libraries are in output/staging/usr/include (which is a
symlink to output/hosr/usr/$tripplet)

We do plenty (hundreds) of tests of packages using C++ every single day
on http://autobuild.buildroot.net, so it would be very odd if Buildroot
didn't copy things correctly.


 > As a test I made a make clean, configured buildroot to use and
 > download the codesourcery toolchain 2013.05m but still the same issue.

 > What I'm doing wrong here ?? 

 > buildroot .confg and the projects .mk included. 

 > Many thanks. 

 > BartT 



 > ################################################################################
 > #
 > # nmcmdserver
 > #
 > ################################################################################

 > NMCMDSERVER_VERSION = 1.0
 > NMCMDSERVER_NAME = nmcmdserver
 > NMCMDSERVER_SITE = package/nikon/nmcmdserver/
 > NMCMDSERVER_SITE_METHOD = local
 > NMCMDSERVER_CONF_OPT = --disable-shared --enable-static
 > NMCMDSERVER_LIBFOO_DEPENDENCIES = nm_libraries

Without the source code of nmcmdserver and nm_libraries there isn't much
we can do until you provide some more information of what exactly goes
wrong.

-- 
Bye, Peter Korsgaard

[Buildroot] buildroot does not copy the C++ headers to sysroot

[Peter Korsgaard]

>>>>> "bart" == bart thoelen <bart.thoelen@telenet.be> writes:

Hi,

Please keep the mailing list in CC so others can help.

 > Hi,
> when searching in the staging directory, none of the C++ headers
> (string, vector ... ) showup.

That is because those headers are part of the toolchain, so they are not
actually present in usr/include.

E.G.:

cat defconfig
BR2_arm=y
BR2_cortex_a9=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201305=y

find output/host -name string
output/host/opt/ext-toolchain/arm-none-linux-gnueabi/include/c++/4.7.3/string
output/host/opt/ext-toolchain/arm-none-linux-gnueabi/include/c++/4.7.3/debug/string

And it gets correctly found by the cross compiler:

cat test.cpp
#include <iostream>
#include <string>

int main(void)
{
  std::string s("hello world");
  std::cout << s << std::endl;
  return 0;
}

strace -e open -f ./output/host/usr/bin/arm-none-linux-gnueabi-g++ -o test test.cpp 2>&1 | grep string
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/bits/stringfwd.h", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/string", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/bits/basic_string.h", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/bits/basic_string.tcc", O_RDONLY|O_NOCTTY|O_LARGEFI


 > Below is the output of the build process during the nm_libraries.

 > I guess due to the absence of the C++ header files, the configure "assumes" they are on /usr/include.

 > A snap out of the build process...

 > checking string usability... no
 > checking string presence... no
 > checking for string... no
 > checking vector usability... no
 > checking vector presence... no
 > checking for vector... no

And what does config.log show regarding these tests?

 >>>> nm_libraries 1.0 Building
 > PATH="/home/bartt/dx2/buildroot-2014.08/output/host/bin:/home/bartt/dx2/buildroot-2014.08/output/host/sbin:/home/bartt/dx2/buildroot-2014.08/output/host/usr/bin:/home/bartt/dx2/buildroot-2014.08/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/uClinux_10r1-4/bfin-uclinux/bin:/opt/uClinux_10r1-4/bfin-elf/bin/:/opt/freescale-coldfire-4.2/bin/:/opt/Xilinx/SDK/2013.4/gnu/arm/lin/bin:/opt/Xilinx/SDK/2013.4/bin/lin"
 > /usr/bin/make -j3 -C
 > /home/bartt/dx2/buildroot-2014.08/output/build/nm_libraries-1.0/
 > make[1]: Entering directory `/home/bartt/dx2/buildroot-2014.08/output/build/nm_libraries-1.0'
 > Making all in nmcriticalsection
 > make[2]: Entering directory
 > `/home/bartt/dx2/buildroot-2014.08/output/build/nm_libraries-1.0/nmcriticalsection'
 > /bin/bash ../libtool --tag=CXX --mode=compile
 > /home/bartt/dx2/buildroot-2014.08/output/host/usr/bin/arm-xilinx-linux-gnueabi-g++
 > -DPACKAGE_NAME=\"amfwcommonlibs\" -DPACKAGE_TARNAME=\"amfwcommonlibs\"
 > -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"amfwcommonlibs\ 1.0\"
 > -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
 > -DPACKAGE=\"amfwcommonlibs\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1
 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
 > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
 > -DHAVE_STDLIB_H=1 -DHAVE_STDIO_H=1 -DHAVE_DLFCN_H=1
 > -DLT_OBJDIR=\".libs/\" -I.  -I/usr/include -Wall -O3 -Werror

-I/usr/include is wrong for cross compilation, so that's why it fails
below. config.log will most likely contain hints about why the configure
test failed.

-- 
Bye, Peter Korsgaard 

[Buildroot] buildroot does not copy the C++ headers to sysroot

[bart.thoelen at telenet.be]

Hi,

I found the problem.  It was using the -I(includedir) in the Makefile.am of the projects.
This was causing the Makefile to get the headers from /usr/include.

The hint "look at config.log" did wonders to me ;).  Thanks.  

>>> nmcmdserver_CPPFLAGS = -I$(includedir) -Wall -O3 -Werror -DNMSERVER_BUILD=$(SVN_REVISION)

I did this to let the Make automatically look for headers in the install directory (looked convenient to use libraries that way).

Now it puzzles me why this works in our custom make-file/batch-file build system.

Anyway, Case closed.

many thanks.

Greetz,

BartT

----- Original Message -----
From: "Peter Korsgaard" <peter@korsgaard.com>
To: "bart thoelen" <bart.thoelen@telenet.be>, buildroot at uclibc.org
Sent: Monday, November 24, 2014 4:00:16 PM
Subject: Re: buildroot does not copy the C++ headers to sysroot

>>>>> "bart" == bart thoelen <bart.thoelen@telenet.be> writes:

Hi,

Please keep the mailing list in CC so others can help.

 > Hi,
> when searching in the staging directory, none of the C++ headers
> (string, vector ... ) showup.

That is because those headers are part of the toolchain, so they are not
actually present in usr/include.

E.G.:

cat defconfig
BR2_arm=y
BR2_cortex_a9=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201305=y

find output/host -name string
output/host/opt/ext-toolchain/arm-none-linux-gnueabi/include/c++/4.7.3/string
output/host/opt/ext-toolchain/arm-none-linux-gnueabi/include/c++/4.7.3/debug/string

And it gets correctly found by the cross compiler:

cat test.cpp
#include <iostream>
#include <string>

int main(void)
{
  std::string s("hello world");
  std::cout << s << std::endl;
  return 0;
}

strace -e open -f ./output/host/usr/bin/arm-none-linux-gnueabi-g++ -o test test.cpp 2>&1 | grep string
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/bits/stringfwd.h", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/string", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/bits/basic_string.h", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 3
[pid 17378] open("/home/peko/source/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/include/c++/4.7.3/bits/basic_string.tcc", O_RDONLY|O_NOCTTY|O_LARGEFI


 > Below is the output of the build process during the nm_libraries.

 > I guess due to the absence of the C++ header files, the configure "assumes" they are on /usr/include.

 > A snap out of the build process...

 > checking string usability... no
 > checking string presence... no
 > checking for string... no
 > checking vector usability... no
 > checking vector presence... no
 > checking for vector... no

And what does config.log show regarding these tests?

 >>>> nm_libraries 1.0 Building
 > PATH="/home/bartt/dx2/buildroot-2014.08/output/host/bin:/home/bartt/dx2/buildroot-2014.08/output/host/sbin:/home/bartt/dx2/buildroot-2014.08/output/host/usr/bin:/home/bartt/dx2/buildroot-2014.08/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/uClinux_10r1-4/bfin-uclinux/bin:/opt/uClinux_10r1-4/bfin-elf/bin/:/opt/freescale-coldfire-4.2/bin/:/opt/Xilinx/SDK/2013.4/gnu/arm/lin/bin:/opt/Xilinx/SDK/2013.4/bin/lin"
 > /usr/bin/make -j3 -C
 > /home/bartt/dx2/buildroot-2014.08/output/build/nm_libraries-1.0/
 > make[1]: Entering directory `/home/bartt/dx2/buildroot-2014.08/output/build/nm_libraries-1.0'
 > Making all in nmcriticalsection
 > make[2]: Entering directory
 > `/home/bartt/dx2/buildroot-2014.08/output/build/nm_libraries-1.0/nmcriticalsection'
 > /bin/bash ../libtool --tag=CXX --mode=compile
 > /home/bartt/dx2/buildroot-2014.08/output/host/usr/bin/arm-xilinx-linux-gnueabi-g++
 > -DPACKAGE_NAME=\"amfwcommonlibs\" -DPACKAGE_TARNAME=\"amfwcommonlibs\"
 > -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"amfwcommonlibs\ 1.0\"
 > -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
 > -DPACKAGE=\"amfwcommonlibs\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1
 > -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
 > -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
 > -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
 > -DHAVE_STDLIB_H=1 -DHAVE_STDIO_H=1 -DHAVE_DLFCN_H=1
 > -DLT_OBJDIR=\".libs/\" -I.  -I/usr/include -Wall -O3 -Werror

-I/usr/include is wrong for cross compilation, so that's why it fails
below. config.log will most likely contain hints about why the configure
test failed.

-- 
Bye, Peter Korsgaard 

[Buildroot] buildroot does not copy the C++ headers to sysroot

[Peter Korsgaard]

>>>>> "bart" == bart thoelen <bart.thoelen@telenet.be> writes:

 > Hi,
 > I found the problem.  It was using the -I(includedir) in the Makefile.am of the projects.
 > This was causing the Makefile to get the headers from /usr/include.

 > The hint "look at config.log" did wonders to me ;).  Thanks.  

Great, good to hear.

 >>>> nmcmdserver_CPPFLAGS = -I$(includedir) -Wall -O3 -Werror -DNMSERVER_BUILD=$(SVN_REVISION)

 > I did this to let the Make automatically look for headers in the
 > install directory (looked convenient to use libraries that way).

 > Now it puzzles me why this works in our custom make-file/batch-file build system.

Perhaps you don't pass a custom --prefix or --includedir? Target
packages in Buildroot are built with --prefix=/usr (and includedir
defaults to $prefix/include), E.G. the path that it will use on the
target, not a path on your build host. This is done as the prefix (and
derived variables like includedir) is used at runtime for some packages
(to find plugins, executables and so on).

 > Anyway, Case closed.

 > many thanks.

You're welcome.

-- 
Bye, Peter Korsgaard