Confirming - blitzing this directory, https://github.com/raspberrypi/tools/tree/f5642106425d430e1f82ee064121a5fd0e05a386/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/lib/gcc/arm-linux-gnueabihf/4.8.3/include/ssp
Gets the compilation moving further... Next status update coming soon > On 31 Jan 2016, at 11:21, Dave Tucker <[email protected]> wrote: > > Looks like my problem might be related to not picking up the includes from > within `--sysroot` > I don't have any ssp headers on my host system (`dpkg -l | grep ssp` is empty) > `find / -name ssp.h` only yields results from within the netbsd-src or the my > toolchain directories > > I can force include > /path/to/obj-evbearmhf-el-hw-raspberrypi/rumptools/dest/usr/include/ssp > Which gets compilation a little further, but causes issues later on with as > `ssp/stdio.h` shadows `stdio.h` > >> On 30 Jan 2016, at 10:31, Antti Kantee <[email protected]> wrote: >> >> On 29/01/16 22:28, Dave Tucker wrote: >>>> See >>>> http://wiki.rumpkernel.org/Info%3A-Notes-on-hardware-platforms#raspberry-pi >>>> >>>> I filed a NetBSD PR about that "spoiler" years ago, don't remember what >>>> the conclusion was off the top of my head, but anyway, the workaround >>>> should be fine. At least it worked when I last was building for RPi. >>> >>> Thanks! >>> I tried it out today with the official compiler and it complained if >>> couldn't find <ssp.h> >>> After adding `-I<long path to rpi compiler>/includes/ssp` to CFLAGS I'm now >>> getting more errors along the lines of: >>> >>> '__ssp_real' declared as function returning a function >>> >>> I think this is a gcc related issue, so next step is to see if I can >>> rebuild the compiler with support for gcc >= 4.9 >> >> It's a known problem, but the only known workaround -- known to me at any >> rate -- is to uninstall the host ssp headers. See: >> https://github.com/rumpkernel/rumprun/issues/14 >> >> In case someone's tweakfinger is tingling, a solution for that would be very >> welcome. >> >
