building Kobo development environment

[BloodRagg]

Originally Posted by NiLuJe

If you don't actually need to play with Qt, unlike this thread implies: https://github.com/koreader/koxtoolchain

If you do need to play with Qt, good luck. If you do, AFAICT, for Qt4, you're better off matching Sergey's toolchain, which is probably documented somewhere... For Qt5, Kobo's latest toolchain, which you can suss out from current FW binaries.

Found it this morning, compiling took over an hour on my horrible machine.
Its a great piece of work though but the binaries it produced segfaulted also

Live CD also produced segfaulted binaries, so i know its something im missing

Originally Posted by NiLuJe

Note that in dropbear's specific case, libtom* is involved. If you opt to build against an external copy, it will not build against current libtomcrypt.

Both options should work though: I build it against external copies, KOReader against the internal ones, and it behaves in both cases.

That could be my problem..i tried almost everything, but then again im quite the noob.

[pazos]

If you want to build qt applications with koxtoolchain you'll need to link statically against libstdc++, because system is too old for modern toolchains.

Add the following to your pro file (of course edit the path first):

LIBS += /home/pazos/x-tools/arm-kobo-linux-gnueabihf/arm-kobo-linux-gnueabihf/lib/libstdc++.a
QMAKE_LFLAGS += -static-libstdc++

You can build Qt 4.8.5 with koxtoolchain without problems, but you'll need to repurpose Sergey's drivers for touchscreen, framebuffer and keypad (or luck into his sources and add these drivers to Qt, but it's more work)

[NiLuJe]

Time to fire up GDB...

(I smell hardfp/softp shenanigans, as Kobo's dynamic loader is slightly finicky on that front).

[BloodRagg]

@NiLuJe
gdb ? you give me way too much credit

@pazos
Toolchain was from 2013, so i needed the lib32stdc++6 package. Afaict this could have been used by the compiler.

So I tried your static linking, (one step forward) the results were slightly different but still no dice
Then I removed the lib32stdc++6 package and tried the latest koxtoolchain as its 64-bit

Makes no difference, I either end up with a 'segfault' or 'illegal Instruction'.

I'm feeling quite hopeless here

[NiLuJe]

Try attaching a simple hello world you built so we can check how exactly it crashes .

[BloodRagg]

Hmm...that compiles and runs just fine.

[NiLuJe]

What's the actual target device, and on which FW version? And what kind of CFLAGS are you passing?

EDIT: As far as dropbear is concerned, you may also want to *disable* hardening, as that's been broken since since the latest release on my end (with a hang, not a crash, though).

[BloodRagg]

Found the %$£$@£$£ £4 problem, linker defaulted to build system instead of host/target.

>> LD=arm-linux-gnuabihf << fixed the problem in my case.

So I configured all those other variables as well CC GXX AR NM OBJCOPY etc.. etc..

Silly me thought make CROSS_COMPILE=arm-linux-gnuabihf- would be enough.

@NiLuJe, how did you compile 2018.76, mine keeps asking for glibc 2.25 which relies on kernel 3.2.0 ?

Furthest i came was 2016.72

[NiLuJe]

@BloodRagg: What's asking for glibc 2.25? The configure or the binaries at runtime? Which what TC?

[BloodRagg]

Originally Posted by NiLuJe

@BloodRagg: What's asking for glibc 2.25? The configure or the binaries at runtime? Which what TC?

Binaries:
[root@(none) tmp]# ./sbin/dropbear
./sbin/dropbear: /lib/libc.so.6: version `GLIBC_2.25' not found (required by ./sbin/dropbear)
[root@(none) tmp]#

TC: gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf
PKG: dropbear-2019.77

[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 .

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.

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 .

[BloodRagg]

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

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.

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

/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$

[NiLuJe]

Full configure and build output would be more helpful .

[BloodRagg]

Logs:
So, I switched toolchains from linaro to kox:
- glibc 2.23 wont compile under kox, symbol error, so i figured well might as well go with 2.15 because kox does. wont compile either
- dropbear 2019.77 does compile under kox only not with multi under linaro it would but i would be facing glibc too old error.

Its like throwing craps in Vegas, its probably me but geez louise I'm going mad

[NiLuJe]

Why do you want to compile the glibc? It's a *very* hairy process, best left to dedicated tools (f.g., buildroot), that no-one not actually building a distro should ever need to go through.