Fix compilation with strict libc (such as musl)
ClosedPublic

Authored by mpyne on Jul 11 2017, 3:30 PM.

Details

Summary

Many of the functions we use implicitly are not part of the C standard
library so we have to specific that we're pulling from POSIX, X/Open,
BSD, or whatever standard we're using before we can rely on the
definition being available.

There's plenty of room for refactoring here since I mostly stopped at
just getting the functions being called to show up from their includes,
although I did replace rindex with strrchr since the latter is
standardized, and replaced uint with unsigned rather than trying to figure out
what header includes those.

(Updated to choose the right repository, this isn't libksysguard but instead kde/workspace/ksysguard)

Test Plan

Now compiles against musl libc
Still compiles against glibc.

Diff Detail

Repository
R106 KSysguard
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
mpyne created this revision.Jul 11 2017, 3:30 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJul 11 2017, 3:30 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
mpyne edited the summary of this revision. (Show Details)Jul 11 2017, 3:40 PM
mpyne removed a reviewer: Frameworks.
mpyne changed the repository for this revision from R111 KSysguard Library to R106 KSysguard.
mart accepted this revision.Jul 12 2017, 11:01 AM
This revision is now accepted and ready to land.Jul 12 2017, 11:01 AM
This revision was automatically updated to reflect the committed changes.
mpyne added a comment.Jul 17 2017, 7:33 PM

Thanks. Looks from the build log like it's not good enough to define the _POSIX_C_SOURCE macro and let it take a default meaning, it needs to be defined to a specific value. I've pushed a fix which I hope will make it through CI.

Thanks for the quick fix.

Getting closer - got a different error this time...
https://build.kde.org/job/Plasma%20ksysguard%20kf5-qt5%20FreeBSDQt5.7/7/

mpyne added a comment.Jul 19 2017, 9:31 PM

Thanks for the quick fix.

Getting closer - got a different error this time...
https://build.kde.org/job/Plasma%20ksysguard%20kf5-qt5%20FreeBSDQt5.7/7/

This fix wasn't as quick, I had to regenerate my musl environment, but I've pushed a commit which should hopefully make it to the end by removing an unneeded internal include (sys/file.h).

Sorry, looks like it's still unhappy (another different error). This time it's complaining about gettimeofday()
According to https://github.com/kinetiknz/cubeb/issues/6 defining XOPEN_SOURCE will sort this, but i'm not sure if musl is okay with that?

Sorry, looks like it's still unhappy (another different error). This time it's complaining about gettimeofday()
According to https://github.com/kinetiknz/cubeb/issues/6 defining XOPEN_SOURCE will sort this, but i'm not sure if musl is okay with that?

musl is fine with XOPEN_SOURCE as long as it's defined properly. It implies _POSIX_C_SOURCE in the FreeBSD headers anyways, though musl amusingly doesn't care at all for gettimeofday. musl *did* care for signals-related functions, but it defines those under _XOPEN_SOURCE as well (see https://anonscm.debian.org/cgit/collab-maint/musl.git/tree/include/signal.h). I'll take a look.