| Summary: | PulseAudio fails to build on musl libc | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Carlo Landmeter <clandmeter> |
| Component: | core | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | clandmeter, lennart, raj.khem, vladimir |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=87849 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Fix | ||
I wonder if this is really a PulseAudio problem. I looked at ioctl as that was the first build problem. In the glibc headers (copy/paste from /usr/include/x86_64-linux-gnu/sys/ioctl.h) it is defined as: extern int ioctl (int __fd, unsigned long int __request, ...) __THROW; If musl libc defines ioctl as "int ioctl(int, int, ...)" instead of "int ioctl(int, unsigned long int, ...)", then that looks like a bug in either musl libc or glibc, not PulseAudio. Could you confirm with the Musl people? No need to confirm I think - the POSIX specification specifies the ioctl(int, int, ...) prototype: http://pubs.opengroup.org/onlinepubs/9699919799/functions/ioctl.html (previous versions also have the same, just linking to the latest one). So this is yet another instance of glibc being glibc... For ioctl specifically, the current `#ifdef sun` can probably be changed to check _XOPEN_SOURCE >= 500 (or similar, I have not tried it and instead patched it directly). I will have a build of pulseaudio 6.0 to test soon on my desktop which I will test and report with any further issues. By the way, what was the reasoning behind reusing the system stat/open/ioctl function names in padsp.c specifically - I see that there are functions like pa_fopen_* already defined elsewhere? (In reply to Vladimir from comment #2) > By the way, what was the reasoning behind reusing the system stat/open/ioctl > function names in padsp.c specifically - I see that there are functions like > pa_fopen_* already defined elsewhere? The point of padsp is to wrap programs that use the OSS interface on systems without OSS. For example, when the program calls open("/dev/dsp"), padsp has to somehow intercept that call, because otherwise the call will just fail. padsp does the interception by redefining the open() function. Created attachment 131823 [details] [review] Fix Thanks a lot for the fix! I applied it to the "next" branch, so it will be released in pulseaudio 12.0. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I'm receiving the following error when building PA 5.0 on Musl libc. utils/padsp.c:2376:5: error: conflicting types for 'ioctl' int ioctl(int fd, unsigned long request, ...) { ^ In file included from utils/padsp.c:36:0: /usr/include/sys/ioctl.h:9:5: note: previous declaration of 'ioctl' was here int ioctl (int, int, ...); ^ utils/padsp.c:2516:5: error: redefinition of 'stat' int stat64(const char *pathname, struct stat64 *buf) { ^ In file included from utils/padsp.c:40:0: /usr/include/sys/stat.h:73:5: note: previous definition of 'stat' was here int stat(const char *__restrict, struct stat *__restrict); ^ utils/padsp.c:2550:5: warning: no previous prototype for 'open64' [-Wmissing-prototypes] int open64(const char *filename, int flags, ...) { ^ utils/padsp.c:2574:5: warning: no previous prototype for '__open64_2' [-Wmissing-prototypes] int __open64_2(const char *filename, int flags) { ^ utils/padsp.c:2676:7: error: redefinition of 'fopen' FILE *fopen64(const char *filename, const char *mode) { ^ In file included from utils/padsp.c:46:0: /usr/include/stdio.h:63:7: note: previous definition of 'fopen' was here FILE *fopen(const char *__restrict, const char *__restrict); ^ Makefile:8164: recipe for target 'utils/libpulsedsp_la-padsp.lo' failed make[3]: *** [utils/libpulsedsp_la-padsp.lo] Error 1