Quote:
Originally Posted by NiLuJe
How was that TC built? koxtoolchain targets glibc-2.15, so it can't pull newer symbols unless you're doing things wrong  .
See my earlier mention of disabling hardening, but even if that fixes it, that doesn't mean that your setup isn't seriously broken . |
A beginners charm
Quote:
Originally Posted by NiLuJe
Speaking of: exceedingly few things should require you to manually enforce CC, CXX, AR, NM, LD & friends. Very few things actually rely on a CROSS_something env var either (OTOH, busybox and OpenSSL would be two exceptions, each expecting a slightly different env var, with a slightly different syntax, IIRC).
What *is* almost ubiquitous, though, is autotool's confusingly named --host argument, which accepts a toolchain triplet, and automatically obeys it to set CC & co.
|
I noticed, but i was confused
about it.
Quote:
Originally Posted by NiLuJe
EDIT: As far as 2019.77 is concerned, my best guess is you're picking up your system includes/glibc because of aforementioned mistakes, and as such it's detecting strlcat/strlcpy as available, while they're definitely not . |
I think it was toolchain based as it compiles properly now, but fails when i try to do a make install.It complains about an ld linking problem.
It works when i remove the MULTI=1 though, but i really want it as an multiexec
Code:
/tmp/autobuild/gcc-kox-7.4.1-2019.02-1f65f8d-x86_64-arm-kobo-linux-gnueabihf/bin/../lib/gcc/arm-kobo-linux-gnueabihf/7.4.1/../../../../arm-kobo-linux-gnueabihf/bin/ld.bfd: /tmp/autobuild/gcc-kox-7.4.1-2019.02-1f65f8d-x86_64-arm-kobo-linux-gnueabihf/bin/../arm-kobo-linux-gnueabihf/sysroot/usr/lib/Scrt1.o: in function `_start':
init.c:(.text+0x4c): undefined reference to `main'
collect2: error: ld returned 1 exit status
Makefile:192: recipe for target 'dropbear' failed
make: *** [dropbear] Error 1
/tmp/autobuild/dropbear-2019.77$