[Chimera] Musl libc and Clang compiler support

[KyunLFA]

As of now attempting to compile on Musl+Clang produces the following errors and warnings (devel branch):

x86_64/corefreq.h:305:27: error: field has incomplete type 'struct random_data'
                     struct random_data data;
                                        ^
x86_64/corefreq.h:305:15: note: forward declaration of 'struct random_data'
                     struct random_data data;
                            ^
x86_64/corefreqd.c:1090:48: warning: format specifies type 'unsigned long' but the argument has type 'pthread_t' (aka 'struct __pthread *') [-Wformat]
                printf("    Thread [%lx] Init CYCLE %03u\n", tid, cpu);
                                    ~~~                      ^~~
x86_64/corefreqd.c:1244:46: warning: format specifies type 'unsigned long' but the argument has type 'pthread_t' (aka 'struct __pthread *') [-Wformat]
                printf("    Thread [%lx] %s CYCLE %03u\n", tid,
                                    ~~~                    ^~~
x86_64/corefreqd.c:1273:11: error: call to undeclared function 'random_r'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                    if (random_r(&RO(Shm)->Cpu[cpu].Slice.Random.data,
                        ^
x86_64/corefreqd.c:1335:48: warning: format specifies type 'unsigned long' but the argument has type 'pthread_t' (aka 'struct __pthread *') [-Wformat]
                printf("    Thread [%lx] Init CHILD %03u\n", tid, cpu);
                                    ~~~                      ^~~
x86_64/corefreqd.c:1384:46: warning: format specifies type 'unsigned long' but the argument has type 'pthread_t' (aka 'struct __pthread *') [-Wformat]
                printf("    Thread [%lx] %s CHILD %03u\n", tid,
                                    ~~~                    ^~~
x86_64/corefreqd.c:8251:19: error: incompatible pointer to integer conversion assigning to 'pid_t' (aka 'int') from 'pthread_t' (aka 'struct __pthread *') [-Wint-conversion]
        RO(Shm)->App.Svr = tid;
                         ^ ~~~
x86_64/corefreqd.c:8736:3: error: call to undeclared function 'initstate_r'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
                initstate_r(    seed32,
                ^
x86_64/corefreqd.c:8736:3: note: did you mean 'initstate'?
/usr/include/stdlib.h:118:7: note: 'initstate' declared here
char *initstate (unsigned int, char *, size_t);

Please consider adding support for Clang and Musl libc when time and effort resources allow.

Thank you for your kind work. Cheers.

[cyring]

Hello,

FYI Clang + GNU libc are building and running fine

I will give a look to Musl. According to your compilation log, a few functions remains to wrap for compatibility mode.

[KyunLFA]

Thank you very much, I look forward to testing it!

[cyring]

Thank you very much, I look forward to testing it!

Can you describe your environment ?

• Linux distribution
• Kernel headers package with Musl ?
• Compiler: Clang only or both Clang + GCC
• Kernel fully built with Clang ? with Musl ?

[cyring]

Some notes:

• HAVE_RANDOM_R
• pacman -S musl
• make CC=musl-gcc clean all

[KyunLFA]

Thank you very much, I look forward to testing it!

Can you describe your environment ?

• Linux distribution
• Kernel headers package with Musl ?
• Compiler: Clang only or both Clang + GCC
• Kernel fully built with Clang ? with Musl ?

Sorry for the delay.

1 Chimera Linux 2 Yes 3 Clang only 4 Yes

Chimera is a new OS I'm trying out. It's ground up LLVM+Musl. https://chimera-linux.org/

*more info:

I am using the CachyOS kernel compiled from source with the official Chimera build tool, with BORE-EEVDF enabled. Kernel works fine. Another user of the OS reproduced the issue as well.

[cyring]

The development branch contains some code for the musl library

So far, I'm just able to build and run CoreFreq for musl with ArchLinux

## as user
make CC=musl-gcc clean all
## as root
insmod CoreFreq/build/corefreqk.ko
CoreFreq/build/corefreqd -d
## as user
CoreFreq/build/corefreq-cli

1. There's a regression to detect the current locale with musl. It is now forced to "en_US.UTF-8" (if not GLIBC) but can be changed afterward from the UI
2. Posix Thread is somehow odd within musl: misc types issue ...

The live base Chimera is downloaded and emulates with QEMU Within the VM are installed the followed packages but make appears incomplete when compared to the GNU Make

apk add gmake bmake git clang linux-headers

git clone -b develop https://github.com/cyring/CoreFreq.git

make

make: line 35: Invalid line type
...
make: stopped

Can you help with those specifics of Chimera ?

[JamiKettunen]

@cyring I see you already installed gmake but you also need to call it as such since bmake is the default make on chimera (which only imlements the POSIX make spec afaik)

Btw testing on https://alpinelinux.org/ may also help as it's using musl too

[cyring]

@cyring I see you already installed gmake but you also need to call it as such since bmake is the default make on chimera (which only imlements the POSIX make spec afaik)

Btw testing on https://alpinelinux.org/ may also help as it's using musl too

I believe I have tried all binaries coming with these 2 packages but none is working as expected from a "standard" GNU make I mean any conditional instruction within my Makefile like ifeq is not recognized!

[JamiKettunen]

@cyring I just tested running gmake and it seems the develop branch Makefile uses GNU extensions for ln command at least (ln -r) which isn't implemented by either the FreeBSD coreutils (basically what Chimera uses) nor busybox (what Alpine uses); in this case you can use $(PWD)/... instead of making relative symlinks I suppose

[cyring]

@JamiKettunen Thanks for your help. Those GNU extensions are making the job since kernel 3.1 . I still also have to qemu Alpine for a build test.

[cyring]

The development branch contains some code for the musl library

So far, I'm just able to build and run CoreFreq for musl with ArchLinux

## as user
make CC=musl-gcc clean all
## as root
insmod CoreFreq/build/corefreqk.ko
CoreFreq/build/corefreqd -d
## as user
CoreFreq/build/corefreq-cli

1. There's a regression to detect the current locale with musl. It is now forced to "en_US.UTF-8" (if not GLIBC) but can be changed afterward from the UI
2. Posix Thread is somehow odd within musl: misc types issue ...

The live base Chimera is downloaded and emulates with QEMU Within the VM are installed the followed packages but make appears incomplete when compared to the GNU Make

apk add gmake bmake git clang linux-headers

git clone -b develop https://github.com/cyring/CoreFreq.git

make

make: line 35: Invalid line type
...
make: stopped

Can you help with those specifics of Chimera ?

@KyunLFA As the original author of the issue, I would appreciate to read your answer about the fix mentioned above ?

[cyring]

Chimera ckms within chimera-linux-x86_64-LIVE-20230915-gnome.iso

doas mkdir -p /opt/src
doas chgrp anon /opt/src
doas chmod g+w /opt/src
cd /opt/src

doas apk add git nano
git clone -b develop https://github.com/cyring/CoreFreq.git
nano /opt/src/CoreFreq/ckms.ini

doas apk add ckms linux-headers linux-lts-devel
doas ckms add /opt/src/CoreFreq/

doas ckms build corefreqk=1.97.0

---

@q66 May you please help with ckms.ini ?

[cyring]

Thread dead

[q66]

sorry, but i missed the message here - got lost among other emails

the main issue with the ckms.ini is the module/, you have no such path in the repository so you should not be using it - just drop the -C, and the module/ prefix from the input path

the destination path should probably match the one in your dkms.conf instead of the one you used

also, initramfs should probably be set to no? does it make sense to rebuild initramfs for this module?

[cyring]

sorry, but i missed the message here - got lost among other emails

the main issue with the ckms.ini is the module/, you have no such path in the repository so you should not be using it - just drop the -C, and the module/ prefix from the input path

the destination path should probably match the one in your dkms.conf instead of the one you used

also, initramfs should probably be set to no? does it make sense to rebuild initramfs for this module?

Thanks for your help.

In my development branch only, I'm committing 7459602f68216cfe25ad6b406179fb8b34daef8a , the ongoing version of the ckms.ini which now fails at the end of the build

[q66]

the last section should look like this instead:

[module.corefreqk]
path = build
dest = kernel/drivers/misc

then it will build as well as install

[cyring]

the last section should look like this instead:

[module.corefreqk]
path = build
dest = kernel/drivers/misc

then it will build as well as install

Thanks, it works much better:

[q66]

great, i have some fixes for ckms lined up that i found while testing this, you can commit the ini file as is though

[cyring]

@KyunLFA @JamiKettunen Hello,

So far what you can do from the development branch within Chimera

git clone -b develop https://github.com/cyring/CoreFreq.git
cd CoreFreq
gmake CC=clang

doas insmod build/corefreqk.ko
doas build/corefreqd -q &
./build/corefreq-cli

[cyring]

@JamiKettunen Hello,

Does CoreFreq development branch now build and run with Alpine ?

[cyring]

@JamiKettunen Feel free to come back at any time