[SOLVED] Errors building solfege - links linux-headers

lquidfire · 2024-07-02 11:49:43

Hi all,

I maintain the AUR package 'solfege', and it appears to throw errors during the build IF you have package 'linux-headers' installed.

Output of the 'makepkg' command can be found here: http://0x0.st/Xa2S.txt

Some observations:

With linux-headers installed - even without the linux kernel package installed(!) - the header files are used, and the errors occur. I run linux-lts (with linux-lts-headers), and if I only install linux-headers, I also get the errors. So, makepkg seems to use the linux-headers files, even if that kernel is not installed, but another kernel with its headers.
Without 'linux-headers' installed, there are no errors. A commenter on the AUR suggests that 'linux-api-headers' are used.
With 'linux-lts-headers' installed, there are also no errors.
A comparison of the swab.h files between linux-headers, linux-api-headers, and linux-lts-headers does show differences between the three files.

Where do we go form here? Is there an issue with swab.h from the linux-headers package? Or do we have to look somewhere else for a solution?

Thank you!

Last edited by lquidfire (2024-07-05 07:35:30)

Lone_Wolf · 2024-07-02 13:17:14

Moderator Note : moved to aur issues board.

cryptearth · 2024-07-02 14:23:53

seems to be an upstream bug:
illegal escape sequence '\c'
Somewhere in the source there's something wrong.

lquidfire · 2024-07-02 20:45:19

Hi cryptearth,

That is a warning "only", so I don't think that that is stopping the build.

There are errors just below that that break the build.

***

I have been poking around this and am seriously asking myself if I am on the right track at all.

I found that the reported error "/usr/src/linux/include/uapi/linux/swab.h:48:15: error: unknown type name ‘__attribute_const__’; did you mean ‘__attribute__’?" gets fixed by adding "#include <cdefs.h> to "solfege/soundcard/macro_to_function.c". (it seems highly unlikely that after all these years of solfege having been around, it turns out that there was a missing header-include....)

However, after that a new error presents itself, of the type "/usr/src/linux/include/linux/types.h:20:33: error: conflicting types for ‘fd_set’; have ‘__kernel_fd_set’" (originates from "from solfege/soundcard/solfege_c_midi.c:27").
Googling this brought me down a path of kernel vs userspace fd_set types, and I figured that I had better report here, as there are probably people here that know what is going on, whereas I don't. Really.

Also, I don't understand why these errors don't pop up when you don't have the package "linux-headers" installed ("linux-lts-headers" is working still). Perhaps there was a significant change between linux-6.6 and linux-6.9?

V1del · 2024-07-03 09:41:07

solfege isn't a kernel driver, it should ideally not in any way rely on linux-headers at all. Some include paths in the source seem to be broken, it probably wants to compile against linux-api-headers -- those should be transparent and stable to userspace, otherwise it's a kernel bug.

On checking -- not on my Arch would test otherwise, what happens if you remove -I/usr/src/linux/include from

CFLAGS:=$(CFLAGS) -I/usr/src/linux/include -Wall -pedantic -fPIC -I.

in ./solfege/soundcard/Makefile -- http://git.savannah.gnu.org/cgit/solfeg … kefile#n26

An explicit include of this path for default types "shouldn't" be necessary.

Lone_Wolf · 2024-07-03 09:53:39

lquidfire wrote:

(it seems highly unlikely that after all these years of solfege having been around, it turns out that there was a missing header-include....)

That often happens when compilers start supporting newer standards and set them as default .

Building in a clean chroot (extra-x86_64-build) with devtools does work .
You probably should do that yourself as there are some python modules that probably should be listed as deps .

I was curious why this package needs header files that are typically only needed for building kernel modules and found this in its ./configure --help output :

Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --disable-oss-sound     Do not build module for OSS sound. Use this if you
                          OS don't support OSS
  --enable-winmidi        Build the winmidi.pyd module. This is required to
                          get sound on MS Windows.
  --enable-tuner          the microphone experiment (default: disable). This
                          code is dead, it does not work.

adding --disable-oss-sound to the configure statement in build() made the package build succesfully .

lquidfire · 2024-07-03 10:32:07

@V1del: Thank you, that solved the problem. I will upload a new patch for that.

Soundcard sounds like it could be hardware, therefore kernel-related. Therefore, I don't know if this is a bug for Solfege (GNU), or for the kernel.

@Lone_Wolf: I will look into missing python depends. OSS support is possible desired by some people, so we don't want to disable that.

lquidfire · 2024-07-03 18:16:09

I was going to post still that I had gotten this far:

The error message was (there's a bunch of similar ones):

/usr/src/linux/include/uapi/linux/swab.h:48:15: error: unknown type name ‘__attribute_const__’; did you mean ‘__attribute__’?

This error occurs with linux headers 6.1.2.

I looked up the difference between linux 6.1.1 and 6.1.2, and indeed, uapi/swab.h has a change! This is the change:

diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index 01717181339eb0..0723a9cce747c8 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -3,7 +3,7 @@
 #define _UAPI_LINUX_SWAB_H
 
 #include <linux/types.h>
-#include <linux/stddef.h>
+#include <linux/compiler.h>
 #include <asm/bitsperlong.h>
 #include <asm/swab.h>

I looked into stddef.h and compiler.h, but nothing struck me as a cause for the errors. Indeed, adding stddef.h to "solfege/soundcard/macro_to_function.c" did not fix the errors.

I don't know what exactly the difference is between linux-api-headers and uapi-headers from linux-headers. Both seem to be for userspace. The uapi-headers are perhaps newer than the linux-api-headers and are not the ones that glibc is built against?

In any event: The swab.h headers are different. The differences are following this pattern:

$ diff -Naru /usr/include/linux/swab.h /usr/src/linux/include/uapi/linux/swab.h

--- /usr/include/linux/swab.h   2024-05-07 13:51:13.000000000 +0200
+++ /usr/src/linux/include/uapi/linux/swab.h    2024-06-28 06:32:50.000000000 +0200

...

 #include <linux/types.h>
 #include <linux/stddef.h>

...

-static __inline__  __u16 __fswab16(__u16 val)
+static inline __attribute_const__ __u16 __fswab16(__u16 val)

...

Perhaps these differences are to be expected. In any event, the linux-api-headers work, and a patch with that has been submitted to the AUR package. Thank you V1del and also PS0 on the AUR (he suggested the same solution, albeit with some sed magic that I couldn't follow).

The remaining question is whether this should be filed as a bug somewhere upstream, and whether the bug is with solfege (why are the kernel headers included?), or with linux (difference in userspace swab.h).

Thank you all for your help!

Last edited by lquidfire (2024-07-03 18:21:00)

V1del · 2024-07-04 13:26:15

kernel header differences are normal and expected. Kernel level API is unstable and can break as needed/demanded to implement some change in between kernel versions (though 6.1.1 and 6.1.2 reads somewhat surprising, seeing as that's a minor version) but this should only affect kernel code/kernel modules. Programs that rely on exposed API and aren't actually dealing with kernel space directly, should at most link against linux-api-headers which ideally never regresses. I think the explicit include the code used to make brought things out of order in terms of the include path, and solfege is pulling from headers it never intended to link against

lquidfire · 2024-07-05 07:34:21

Thank you, V1del, and also Lone_Wolf.

I would report a bug to solfege, but it seems that it is pretty much unmaintained upstream.

Arch Linux

#1 2024-07-02 11:49:43

[SOLVED] Errors building solfege - links linux-headers

#2 2024-07-02 13:17:14

Re: [SOLVED] Errors building solfege - links linux-headers

#3 2024-07-02 14:23:53

Re: [SOLVED] Errors building solfege - links linux-headers

#4 2024-07-02 20:45:19

Re: [SOLVED] Errors building solfege - links linux-headers

#5 2024-07-03 09:41:07

Re: [SOLVED] Errors building solfege - links linux-headers

#6 2024-07-03 09:53:39

Re: [SOLVED] Errors building solfege - links linux-headers

#7 2024-07-03 10:32:07

Re: [SOLVED] Errors building solfege - links linux-headers

#8 2024-07-03 18:16:09

Re: [SOLVED] Errors building solfege - links linux-headers

#9 2024-07-04 13:26:15

Re: [SOLVED] Errors building solfege - links linux-headers

#10 2024-07-05 07:34:21

Re: [SOLVED] Errors building solfege - links linux-headers

Board footer