arm-linux-gnueabihg-g++ can't find dbus header files

Question

I was cross compiling a program for raspi (see git pukster/omxplayer-sync-2 ) using the arm-bcm2708 compiler. However, I ran into problems when I tried to get it to run on the raspi2. I have now moved over to using arm-linux-gnueabihf-g++ (see git pukster/omxplayer-sync3 ). I have spent the better part of the day trying to get this cross compiler to work, having finally compiled ffmpeg, but now it complains that it can't find string.

I will include a minimum working example illustrating the problem (using a helloworld program), while using the same g++ call. If you are interested in looking at the full code, you can find it at my github account pukster/omxplayer-sync3

I need someone with more compiler insight to help me diagnose this problem.

helloworld.c

#include<stdio.h>
#include<string>

main()
{
    printf("Hello World");    
}

make.sh

#!/bin/bash

arm-linux-gnueabihf-g++ \
   --sysroot=/mnt/CYBRAN/raspi1 \
   -Wall \
   -isystem/include \
   -pipe \
   -mfloat-abi=hard \
   -mcpu=cortex-a7 \
   -fomit-frame-pointer \
   -mabi=aapcs-linux \
   -mtune=arm1176jzf-s \
   -mfpu=vfp \
   -Wno-psabi \
   -mno-apcs-stack-check \
   -O3 \
   -mstructure-size-boundary=32 \
   -mno-sched-prolog \
   -std=c++0x \
   -D__STDC_CONSTANT_MACROS \
   -D__STDC_LIMIT_MACROS \
   -DTARGET_POSIX \
   -DTARGET_LINUX \
   -fPIC \
   -DPIC \
   -D_REENTRANT \
   -D_LARGEFILE64_SOURCE \
   -D_FILE_OFFSET_BITS=64 \
   -DHAVE_CMAKE_CONFIG \
   -D__VIDEOCORE4__ \
   -U_FORTIFY_SOURCE \
   -Wall \
   -DHAVE_OMXLIB \
   -DUSE_EXTERNAL_FFMPEG \
   -DHAVE_LIBAVCODEC_AVCODEC_H \
   -DHAVE_LIBAVUTIL_OPT_H \
   -DHAVE_LIBAVUTIL_MEM_H \
   -DHAVE_LIBAVUTIL_AVUTIL_H \
   -DHAVE_LIBAVFORMAT_AVFORMAT_H \
   -DHAVE_LIBAVFILTER_AVFILTER_H \
   -DHAVE_LIBSWRESAMPLE_SWRESAMPLE_H \
   -DOMX \
   -DOMX_SKIP64BIT \
   -ftree-vectorize \
   -DUSE_EXTERNAL_OMX \
   -DTARGET_RASPBERRY_PI \
   -DUSE_EXTERNAL_LIBBCM_HOST \
   -marm \
   -isystem/mnt/CYBRAN/raspi1/usr/include \
   -isystem/mnt/CYBRAN/raspi1/usr/include/arm-linux-gnueabihf \
   -isystem/mnt/CYBRAN/raspi1/opt/vc/include \
   -isystem/mnt/CYBRAN/raspi1/usr/include \
   -isystem/mnt/CYBRAN/raspi1/opt/vc/include/interface/vcos/pthreads \
   -isystem/mnt/CYBRAN/raspi1/usr/include/freetype2 \
   -isystem/mnt/CYBRAN/raspi1/usr/include/libavcodec \
   -isystem/mnt/CYBRAN/raspi1/opt/vc/include/interface/vmcs_host/linux
   -isystem/mnt/CYBRAN/raspi1/usr/include/dbus-1.0 \
   -isystem/mnt/CYBRAN/raspi1/usr/lib/arm-linux-gnueabihf/dbus-1.0/include/ \
   -I./ \
   -Ilinux \
   -Iffmpeg_compiled/usr/local/include/ \
   -Iffmpeg/libavutil/ \
   -c helloworld.c \
   -o helloworld \
   -Wno-deprecated-declarations

output

username@sv-01:~/Documents/test$ ./make.sh 
helloworld.c:4:17: fatal error: string: No such file or directory
 #include<string>
                 ^
compilation terminated.
username:~/Documents/test$ ls /mnt/CYBRAN/raspi1/usr/include/string*
/mnt/CYBRAN/raspi1/usr/include/string.h  /mnt/CYBRAN/raspi1/usr/include/strings.h

EDIT: troubleshooting output

Output of find /mnt/CYBRAN/raspi1/usr/include/ -type l

/mnt/CYBRAN/raspi1/usr/include/python2.6/numpy
/mnt/CYBRAN/raspi1/usr/include/c++/4.6.3
/mnt/CYBRAN/raspi1/usr/include/python2.6_d/numpy
/mnt/CYBRAN/raspi1/usr/include/python3.2mu/numpy
/mnt/CYBRAN/raspi1/usr/include/png.h
/mnt/CYBRAN/raspi1/usr/include/pngconf.h
/mnt/CYBRAN/raspi1/usr/include/python3.2dmu/numpy
/mnt/CYBRAN/raspi1/usr/include/python2.7_d/numpy
/mnt/CYBRAN/raspi1/usr/include/numpy
/mnt/CYBRAN/raspi1/usr/include/libpng
/mnt/CYBRAN/raspi1/usr/include/python2.7/numpy

EDIT: When I do an ls on one of the -isystem directories, I can see that the file string exists, but I still get the same complaint. Is this a compatibility issue as mentioned here

This link might be helpful to someone who understands it more than I http://e2e.ti.com/support/arm/sitara_arm/f/791/p/290745/1026136 — puk, Aug 24 '15 at 06:51
I've had similar issues to the linked thread with absolute symlinks when building against a mounted target sysroot (in my case an AArch64 openSUSE). Spent about 10 minutes repeatedly tracking down the next file that failed the build and manually rewriting the symlink as a relative one. Your case may be simpler, though - note that `string.h` is _not_ `string` - I don't know precisely how, if at all, G++ implicitly searches the given paths, but on the 3 cross-compilers I have to hand plus my live x86 box, `string` lives in `/usr/include/c++//`. — Notlikethat, Aug 25 '15 at 11:35
Well, the "get something working" hack would be to just keep adding include paths for all the system headers 'til it builds. Better would be to look into why `--sysroot` isn't working (many of those -isystem options should be completely unnecessary) - on the symlink note, what does `find /mnt/CYBRAN/raspi1/usr/include -type l` give back? I couldn't reproduce the same failure against an Ubuntu armv7 filesystem in /mnt. — Notlikethat, Aug 25 '15 at 19:23
I will update the question to reflect your request, however, as I am sure you are aware, this is on the host machine, not the target — puk, Aug 25 '15 at 19:25
Indeed, it's easier on the host machine because then you can see when absolute symlinks are broken ;) — Notlikethat, Aug 25 '15 at 19:26

arm-linux-gnueabihg-g++ can't find dbus header files

0 Answers0