kobo-reader sdk installation buged on WSL2

[Aramir]

Hello,

I'm trying to install the kobo sdk/toolchain (https://github.com/kobolabs/Kobo-Reader) on my WSL2 (so it is 32 bits compatible) debian (64 bits). But I'm stuck on some automake error when trying to build lcms. I'm stuck with the following log and I don't know automake enough to fix it by my own for now :

aramir@SHODAN:~/kobo/tmp$ ~/kobo/KoboLabs/build/build-all.sh
No need to rebuild openssl
No need to rebuild iconv
No need to rebuild expat
No need to rebuild dbus
No need to rebuild gettext
No need to rebuild glib
No need to rebuild libusb
No need to rebuild zlib
No need to rebuild libzip
No need to rebuild libxml2
No need to rebuild dosfstools
No need to rebuild wireless_tools
No need to rebuild wpa_supplicant
No need to rebuild libpng
No need to rebuild jpegsrc
No need to rebuild busybox
No need to rebuild libtool
No need to rebuild attr
No need to rebuild acl
No need to rebuild udev
No need to rebuild lcms
patching file autogen.sh
~/kobo/tmp/libmng-1.0.10 ~/kobo/tmp
copying configure.in
copying automake template
running aclocal
aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:18: error: automatic de-ANSI-fication support has been removed
/usr/share/aclocal-1.16/obsolete.m4:26: AM_C_PROTOTYPES is expanded from...
configure.in:18: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: echo failed with exit status: 1
running libtoolize
running automake
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in: error: no proper invocation of AM_INIT_AUTOMAKE was found.
configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,
configure.in: that aclocal.m4 is present in the top-level directory,
configure.in: and that aclocal.m4 was recently regenerated (using aclocal)
configure.in:23: installing './install-sh'
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
Makefile.am:12: error: Libtool library used but 'LIBTOOL' is undefined
Makefile.am:12:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
Makefile.am:12:   to 'configure.in' and run 'aclocal' and 'autoconf' again.
Makefile.am:12:   If 'LT_INIT' is in 'configure.in', make sure
Makefile.am:12:   its definition is in aclocal's search path.
building configure script
configure.in:9: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:18: error: possibly undefined macro: AM_C_PROTOTYPES
configure.in:22: error: possibly undefined macro: AM_PROG_LIBTOOL
Build failed at libmng.sh, aborting

Did someone managed to install the sdk ?

I obviously already had tons of little problems prior to that point. Just to name a few :
- tons of libs are not mentioned in the requirements, just read the errors as they come and install what's necessary
- there seem to be a syntax error in openssl pod files so I tweaked its script and changed install -> install_sw to skip the .pod files. So I won't have openssl doc but who cares
- the obscure CodeSourcery require a Java jre AND a x11 server to launch its graphical installer (so I had to configure VcXsrv)
- CodeSourcery refused to run if DASH is the default shell, so I had to turn it off for a short time with dpkg-reconfigure -plow dash
- the damn CodeSourcery arm compiler tools are all named arm-none-linux-gnueabi-SOMETHING instead of arm-linux-SOMETHING so I had to write symbolic links for each of them
-for some reason on debian, libtool doesn't install the libtool binaries, you have to install libtool-bin
- etc

Also I'm trying to install this one because it's the offiicial one and from what I could gather in this thread (https://www.mobileread.com/forums/sh...d.php?t=330120) every other ones have some trade off :
- koxtoolchain (https://github.com/koreader/koxtoolchain) : has a whole paragraph on their github page about a nickel TC version for kobo that basically shouldn't be used. Maybe there is a proper "kobo" version in addition to that "nickel TC" version. It's not really clear so please correct me if I'm in the wrong
- nickelTC (https://github.com/pgaskin/NickelTC) wich sounds just like the "do not use version" mentioned above. Also it's a docker thing, and I don't really like docker, I don't want a VM in my VM in my VM in my VM, etc but meh ok


Thanks for reading so far, any help is appreciated.

[NiLuJe]

That script is essentially stuck in the olden days of the Kobo OG and/or Kobo Touch. Don't use it.

TL;DR:

* If you actually intend to work with the *stock* Qt & QPA, use NickelTC (or build a Dockerless version of it from my scripts, c.f., https://github.com/pgaskin/NickelTC/issues/2 where we just discussed something like that). I'd link to my binaries for this, but, IIRC, the final one is the *sole* file that got eaten by the dreaded OVH fire .
* If you don't, use koxtoolchain & the kobo target. Possibly with a custom Qt5 build & QPA (c.f., UMR & InkBox) if you *really* want new Qt.

So, a good start would be asking *what*, exactly, you're intending to do?

[NiLuJe]

Keep in mind that *none* of this has ever been tested on WSL2.

Well, technically, the koxtoolchain `kobo` target has, since a few crazy persons have tried building & running KOReader in that in the past, and it apparently worked out, minus a few sanity health points, although I don't recall if that was with or without resorting to the koreader docker images .

TL;DR: Cross-compiling is already a fairly nightmarish experience. I'd save myself some trouble and bite the bullet with a real Debian or Arch VM.

[Aramir]

Thanks for the fast answers.

Actually I have no idea what the differences truly are between the stock toolchain, NickelTC and koxtoolchain.

Roughly what I want to do is port/rewrite an application called ohbenkyo (https://play.google.com/store/apps/d...yo&hl=fr&gl=US) for my kobo libra H2O. So I want to :
- print text
- print squares
- print pictures
- touch input support
- a way to serialize / deserialize some informations.

So I guessed already Qt was the way to go which one I don't really care. I'd want the most used / documented one when it comes to ereader devices I guess.

What do you recommend for my case ?

ps : WSL isn't as much nightmarish as it seems to be at first. I managed to build for vita and some obscure devices. But if you wish to give it a try, go WSL2 if you can otherwise you'll be stuck with x86_64 libraries/applications support only.

[NiLuJe]

We don't currently have a sane way to deal with input with the stock QPA, so, you'll probably want to go custom Qt if Qt is what you want.

Or custom all the things and do everything by hand, with FBInk's help, which is also a possibility, depending on how much UI you actually need.

@shermp also had some success by going with a <insert favorite language here> backend + web frontend approach using the stock beta browser (which, fair warning, is an old, old, old, and heavily limited WebKit version).

TL;DR: Not NickelTC after all .

[Aramir]

Ok thanks so I'll probably reinstall my debian and go for the koxtoolchain road.

I'm done for today but will probably come back later on in this thread or another one if it's more appropriate asking for help if anything goes wrong.

[NiLuJe]

Since I mentioned KOReader above, a KOReader plugin may also be an entirely viable approach.

[Aramir]

And now I'm getting somewhere.



So yeah, koxtoolchain work flawlessly with WSL2 Debian.
There was a couple of missing libs and tools by default so

apt-get install unzip git libtool libtool-bin

And you should be ready to go

Next steps would be :
1/ find a way to run the program without using KOReader terminal emulator. I tried to put a shortcut for it on NickelMenu but for some reasons it just spits out
[KFMon] PID 2754 exited unexpectedly : 2! I figured it out, there was indeed a typo in my launcher.
===> I figured out how to run my stuff throught KoReader's SSH server

=====> I'm not sure how I'll go when I'll have to debug my app without KoReader running in the background tho. It seems to use dropbear, so I guess I'll probably have to find a way to run a dropbear server throught NickelMenu prior to launching my app. Or store everything in a .log file. I'm guessing gdb is out of questions anyway.
=========> Or I'll just use your stuff I guess XD https://www.mobileread.com/forums/sh...d.php?t=254214 . There's plenty in here, so I'll have to install that and figure out how it works along the way. This seems to allows GDB throught SSH but is it possible to debug directly from QtCreator thanks to this ?

2/ put the actual helloworld on screen using FBInk (or directly skip to QtCreator stuff)
===> I ended up skipping this step

3/ find out how to use Qt. At the moment I'm compiling using QtCreator inside my debian WSL. so I probably have to download Qt (this seems to be a good place to start https://github.com/Rain92/qt5-kobo-platform-plugin) and recompile it for kobo.
===> For future people reading this, if you have tons numeric_limits related errors it's probably because you're compiling with GCC11. To fix this I simply added : #include <limits> to qt5/qtbase/src/corelib/global/qglobal.h under the #ifdef __cplusplus section.

Also I'm not sure why you mentioned KoReader plugin ? Yes I could write my program as a KoReader plugin but what would be the point, why would I want to :
1/ launch KoReader
2/ go to plugin
3/ launch my plugin
When I can just start it from NickelMenu ? Or am I missing something ?

[NiLuJe]

1/ No idea, I don't use Qt Creator. Assuming it's simply gdb over gdbserver in disguise, probably, as I ship gdbserver. Not my cup of tea, though, I much prefer doing it natively, so I've never really looked into the remote approach. We may have some rudimentary documentation about it in the KOReader wiki, though.

3/ Yup, that'd be the QPA you want. Except it may need some tinkering to deal with the Libra properly.

3b/ Keyword being "may" . The reasoning being it provides a battle-tested implementation of everything you need (i.e., a working UI toolkit) and is fast to prototype and iterate for, because Lua. And will handle any and all low-level device quirks for you, and there are many of those on kobo .

[OfficerAction]

Originally Posted by Aramir

This seems to allows GDB throught SSH but is it possible to debug directly from QtCreator thanks to this ?

I'm using QtCreator and it's perfectly possible to debug kobo apps remotely. You just have to build GDB and GDB server and put the server on your kobo device.

[Aramir]

Originally Posted by OfficerAction

I'm using QtCreator and it's perfectly possible to debug kobo apps remotely. You just have to build GDB and GDB server and put the server on your kobo device.

That's interesting, does it require any specific "kit" modification on QtCreator end ? I never used QtCreator to debug remotely before. For now whenever I try to launch a debug session it fails complaining about a missing XML target description

2:02:10: Checking available ports...
12:02:10: Found 101 free ports.
12:02:10: Starting /usr/bin/gdbserver...
12:02:10: Debugging starts
Listening on port 10000
Remote debugging from host 192.168.1.2, port 1130
Process /mnt/onboard/.adds/Obenkyobo/launcher.sh created; pid = 1815
while parsing target description (at line 4): Target description specified unknown architecture "arm"
Could not load XML target description; ignoring
Killing process(es):
 1815
12:02:11: Application finished with exit code 0.
12:02:11: Debugging has finished

When using gdb-multiarch (instead of gdb) in QtCreator it seems to start correctly but I receive random SIGABRT. So I don't know what's going on here.

I already have gdb and gdbserver on my kobo.

Sorry for the delay, vacation time ! Also I'm hanging out in the discord if you want to explain everything to me over there. It might be faster.

EDIT :

After several experiences I decided to turn on my brain and actually proper read about the error message and gdb-multiarch.

You can make gdb-multiarch work with QtCreator and kobo, you just have to set it correctly for arm by : Tools->Options->Debugger->GDB->Additional Startup Commands : -q --nh -ex 'set architecture arm'

Or use OfficerAction's scripts to cross compile and install gdb for arm https://github.com/Rain92/kobo-qt-setup-scripts


And while you're at it, you might as well as an extra step in the deployment process and have QtCreator run a script to kill nickel and prepare your env variables :
Projects->Kobo(Kit)->Run->Deployment-> Add Run custom remote command : /mnt/onboard/.adds/Obenkyobo/debugEnv.sh (for both Release and debug)

Thanks Niluje, Niluma, OfficerActions for listening to me venting on discord ^^