What a mess this std:: stuff:
https://www.google.com/search?hl=en&num=25&q=%22round%27+is+not+a+member+of+%27std%27%22 on kindle & co
https://www.google.com/search?hl=en&num=25&q=%22to_string%27+is+not+a+member+of+%27std%27%22 on android

I may understand why crengine decided to use its own LV* implementations of all this somehow standard stuff.

Phew, it builds.
2 things I had to hack around (see the above google search urls for details):

• std::round() (used in upstream code) seems to not be available in our kobo/kindle/... toolchains. I had to switch it to ::round().
• std::to_string() (used in upstream code, and my code) seems to not be available in our old android gcc toolchain: I had to implement it (in xtended/xlunasvg.h, which is included in all sources, including upstream code, to keep it simple).

Is that fine with you @NiLuJe ?

I've definitely seen the round thing happen before, and I'm not quite sure why it's messed up, but, yeah, that's what I do on my end, too (well, okay, it's not exactly round here, but basically libm symbols ;p).

The string stuff is probably a guard in libstdc++ against broken libcs, I found similar old issues for MingW, so, yeah, makes sense to fix it on our end.

Random possibly unrelated thing I've noticed when testing on Android today: CRe cache saves appear to be much slower than before, does that ring a bell?

(I have yet to test on an actual device. Keep in mind that's a debug build, too).

Nope :/
The only thing related to cache is koreader/crengine@8dee18c , now using the 2nd function instead of the 1st in https://github.com/koreader/crengine/blob/75ec3f9943e3b2a5fb273053cc026b66b0ee291e/crengine/src/lvstring.cpp#L5629-L5646. You could try reverting this just to see, but it feels like just 2 more peanuts.

I'm not noticing any slowdown on my Android phone with this morning nightly (exiting a big Bible which saves its cache for 15 seconds on my Kobo, takes less than 1 sec on my 6 years old android phone).

Yeah, possibly unrelated Android fuckery, as I'm also seeing 5s stalls on what's apparently building the font list on startup :?.

(And, ofc, it's random).

I've been also seeing some random 5-10s pause on emulator launch over the last days/week :/ Don't remember exactly on what it was pausing (possibly the font list), nor did I think about looking if cpu was at 100%...

Okay, the stall on close is unrelated, it's a quirk of DocCache that I'll be squishing.

(If you open a PDF, scroll a bit, close it, open an ePub, close it; it'll serialize stuff from the PDF).

Fixed the DocCache thing in koreader/koreader#9513

And, of course, I couldn't reproduce the stalls on startup ;p.

Just putting here for reference some link I stumbled on while searching for other things, where somebody did the same kind of test files I had to, and asked some of the same questions, when adding this SVG support:
https://wolthera.info/2022/10/svg-text-layout-for-krita/
https://planet.kde.org/wolthera-van-hovell-tot-westerflier-2022-10-30-svg-text-layout-for-krita/ (same article, more readable here)

Phew, it builds. 2 things I had to hack around (see the above google search urls for details):

std::round() (used in upstream code) seems to not be available in our kobo/kindle/... toolchains. I had to switch it to ::round().

Currently picking stuff from previous patch against LunaSVG master.
With our latest toolchain/build updates, do you think I still have to do the above tweaks for our kobo/kindle.... toolchains - that is, have they been updated?

Since when are we talking about?

Sep 11 2022

No, see https://github.com/koreader/koxtoolchain (and by extension in virdevenv)

But GCC 11.2 isn't exactly old?

std::round() (used in upstream code) seems to not be available in our kobo/kindle/... toolchains. I had to switch it to ::round().

This doesn't sound like something that makes sense. :-/ Maybe just open a PR here so we can see what happens?

Will do.
But I have learned to live with build stuff that doesn't make sense. And so will you :)

The lm math namespace thing is unlikely to have changed, as I haven't actually updated the toolchains yet ;).

Nonsense ! as expected:

/home/ko/base/thirdparty/lunasvg/build/arm-kindle5-linux-gnueabi/lunasvg-prefix/src/lunasvg/source/parser.cpp: In static member function 'static bool lunasvg::Parser::parseColorComponent(const char*&, const char*, int&)':
/home/ko/base/thirdparty/lunasvg/build/arm-kindle5-linux-gnueabi/lunasvg-prefix/src/lunasvg/source/parser.cpp:887:39: error: 'round' is not a member of 'std'; did you mean 'round'?
  887 |     component = static_cast<int>(std::round(value));
      |                                       ^~~~~

In which one was that specifically?

Can't find the CI run with the failure in my history (the latest one may have got the same url) - but from memory, kobo, kindle, pocketboot - and may be 1 or 2 others.

Ah, well, never mind then.

If it were the 18.04 image then I was planning image maintenance anyway. I'd originally planned that for July 2023 but I'm holding off for now to keep a clear view on potential Android TC update issues. But all the images you mentioned aren't relevantly outdated unless CMake is causing it somehow.

Nah, I've seen this when building other stuff on the same TCs (e.g., gdb).