mvglasow

Looking at the history of navit/navit/support/glib, facts about this library stub appear to be: * Stripped-down version of GLib, containing only the essentials needed for Navit * Based on GLib...

Building against a current version comes with the additional challenge that the actual library needs to come from somewhere. Either it has to be available on the platform, or we...

The GLib files in the support version can be divided into three categories: * Navit additions (not present in the upstream version) * Identical copies of their upstream counterparts, down...

Did I really write: > the thread functions are essentially just wrappers around the native ones (either POSIX threads or Win32). They are intended to be low-level, with no further...

Yes, we are currently having issues with the map server, see #1112. Unfortunately, the maintainer of the server seems to have left the project. @jkoan is working on a solution....

@lains thanks, so we seem to have some level of GLib support on WinCE. Unfortunately, by now I know that WinCE runs on the stripped-down (and ancient) support version of...

The FrankenGLib approach does not work well either, as there are still too many dependencies. At the most, we could try updating the entire `support/glib` tree to something recent, but...

We’re making progress: we have a basic thread library that can spawn and join threads and has support for read/write locks (the only synchronization mechanism I am using thus far)....

@hoehnp sure, I am still working on some build issues, then I'll provide a link. There’s still plenty of stuff that is not synced properly between threads, thus crashes and...

All right, build issues are sorted out. @hoehnp Sailfish artifacts are here: https://circleci.com/gh/mvglasow/navit/1601#artifacts/containers/0 (go to the Artifacts tab and choose the package for your architecture). As mentioned, thread synchronization is...