#1932 Packaging for Alpine Linux (busybox/musl)

[Leonardo Arena]

Hi,
I'm trying porting Flightgear into Alpine Linux, which is not a GNU/GLIBC distro but it's musl/busybox-based instead.

I know just some very very basic C/C++ stuff and I attach the only patch I could write to fix compilation under Alpine, which is not enough because compilation fails anyway with:

[  2%] Building C object 3rdparty/iaxclient/lib/CMakeFiles/iaxclient_lib.dir/codec_ulaw.c.o
[  2%] Building C object 3rdparty/hts_engine_API/CMakeFiles/hts_engine.dir/lib/HTS_misc.c.o
/home/larena/aports/testing/flightgear/src/flightgear-2016.4.4/3rdparty/hts_engine_API/lib/HTS_misc.c: In function 'HTS_ftell':
/home/larena/aports/testing/flightgear/src/flightgear-2016.4.4/3rdparty/hts_engine_API/lib/HTS_misc.c:251:26: error: 'fpos_t {aka union _G_fpos64_t}' has no member named '__pos'
       return (size_t) pos.__pos;
                          ^
make[2]: *** [3rdparty/hts_engine_API/CMakeFiles/hts_engine.dir/build.make:159: 3rdparty/hts_engine_API/CMakeFiles/hts_engine.dir/lib/HTS_misc.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:352: 3rdparty/hts_engine_API/CMakeFiles/hts_engine.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

I looked around for anything similar to this error and I could not find anything. Is there anyone which could help me with this?

I'm also attaching CMakeCache.

Thank you very much

• leo

[xDraconian]

@Leonardo,

What's the status of this. Were you able to get it working or did you abandon this porting effort?

[Leonardo Arena]

It's ported. I've used this patch:

--- a/3rdparty/hts_engine_API/lib/HTS_misc.c    2015-02-18 21:10:05.000000000 +0100
+++ b/3rdparty/hts_engine_API/lib/HTS_misc.c    2015-10-31 17:33:53.946349145 +0100
@@ -247,8 +247,10 @@
       fgetpos((FILE *) fp->pointer, &pos);
 #if defined(_WIN32) || defined(__CYGWIN__) || defined(__APPLE__) || defined(__ANDROID__) || defined(__FreeBSD__)
       return (size_t) pos;
-#else
+#elif defined(__GLIBC__)
       return (size_t) pos.__pos;
+#else

+      return (size_t) ftell(fp->pointer);
 #endif                          /* _WIN32 || __CYGWIN__ || __APPLE__ || __ANDROID__ */
    }
    HTS_error(0, "HTS_ftell: Unknown file type.\n");

It would be nice if it could be merged or find a better solution that takes into account musl libc.
Thanks

[James Turner]

Hey, I'm sure building FlightGear on a non-GLibC system is going to work in general? We build on Mac (BSD libC of course) and Windows using their libC, but I don't know if a muLibC is actually feasible.

[Leonardo Arena]

VoidLinux and AlpineLinux (both using musl libc) have packages for it.

I think it would be nice have official support from upstream.

Thanks for considering it!

[James Turner]

Just so I understand, if they have packages, surely they also have patches for the issues you're fixing here? Or how could it build?

[Leonardo Arena]

When I say "official support from upstream" i mean that the source should compile without the need of patching. So if these patches could be considered to be merged or some other more correct/elegant solution be found so that it compiles out-of-the-box also with musl libc.

Thanks!

[James Turner]

You should probably submit this upstream to HTS-engine http://hts-engine.sourceforge.net as well, BTW

[Leonardo Arena]

Ok, good to know

[James Turner]

Hey. looking at the code, is there a reason we can't use fgetpos with musl? I.e is there #define for MUSL to use it in the first case maybe? Using ftell is kind of a step backwards.

[Leonardo Arena]

Why we can't use fgetpos is beyond me. Where there's isn't a macro for musl you'll find the answer here: https://wiki.musl-libc.org/faq.html

[James Turner]

fgetpos is there on Musl, the value type is off_t (64 bit int). But we can't use that without checking if we're using Musl or not. Unless I flip the check and assume only GlibC uses the other version of fpos_t ...