Version 0.0.95 fails to compile on FreeBSD

[ehaupt]

Trying to compile version 0.0.95 I get:

cc -o gbsinfo gbsinfo.o libgbs.a -lintl -fstack-protector-strong -L/usr/local/lib  -lz -Wl,-z,relro -Wl,-z,now -pie -fstack-clash-protection -lm
In file included from plugout_devdsp.c:20:
/usr/include/sys/soundcard.h:243:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      play_rate;      /* sampling rate                        */
    ^  
/usr/include/sys/soundcard.h:244:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      rec_rate;       /* sampling rate                        */
    ^  
/usr/include/sys/soundcard.h:245:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      play_format;    /* everything describing the format     */
    ^ 
/usr/include/sys/soundcard.h:246:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      rec_format;     /* everything describing the format     */
    ^
/usr/include/sys/soundcard.h:256:5: error: unknown type name 'u_char'; did you mean 'char'?
    u_char      subdev; /* which output                         */
    ^
/usr/include/sys/soundcard.h:257:5: error: unknown type name 'u_char'; did you mean 'char'?
    u_char      line;   /* which input                          */
    ^
/usr/include/sys/soundcard.h:258:5: error: unknown type name 'u_char'; did you mean 'char'?
    u_char      left,right; /* volumes, 0..255, 0 = mute        */
    ^
/usr/include/sys/soundcard.h:297:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      rate_min, rate_max;     /* min-max sampling rate */
    ^
/usr/include/sys/soundcard.h:298:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      formats;
    ^
/usr/include/sys/soundcard.h:299:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      bufsize; /* DMA buffer size */  
    ^
/usr/include/sys/soundcard.h:300:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      mixers; /* bitmap of available mixers */
    ^
/usr/include/sys/soundcard.h:301:5: error: unknown type name 'u_long'; did you mean 'long'?
    u_long      inputs; /* bitmap of available inputs (per mixer) */
    ^
/usr/include/sys/soundcard.h:302:5: error: unknown type name 'u_short'; did you mean 'short'?
    u_short     left, right;    /* how many levels are supported */
    ^
/usr/include/sys/soundcard.h:337:2: error: unknown type name 'u_char'; did you mean 'char'?
        u_char arr[8];
        ^
/usr/include/sys/soundcard.h:381:2: error: unknown type name 'u_long'; did you mean 'long'?
        u_long mode;
        ^
/usr/include/sys/soundcard.h:419:2: error: unknown type name 'u_int'
        u_int base_freq;
        ^
/usr/include/sys/soundcard.h:420:2: error: unknown type name 'u_long'; did you mean 'long'?
        u_long base_note;
        ^
/usr/include/sys/soundcard.h:421:2: error: unknown type name 'u_long'; did you mean 'long'?
        u_long high_note;
        ^
/usr/include/sys/soundcard.h:422:2: error: unknown type name 'u_long'; did you mean 'long'?
        u_long low_note;
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]

Including <sys/types.h> does not help.

Full build log

[mmitch]

Through some blind prodding I got it to compile: I've added -D__BSD_VISIBLE=1 manually to the EXTRA_CFLAGS in config.mk after I ran the configure script.

I don't know if gbsplay really works that way, because I only have a remote shell account and can't test it properly.

We'll then have to find out how to set that flag automatically - or even better, what to do so we don't have to set it at all. I've found this bug report https://github.com/kcat/openal-soft/issues/4 that mentions some flags that should not be set or types like u_long and friends will become unavailable.

I think we need some BSD expertise here.

[ehaupt]

Through some blind prodding I got it to compile: I've added -D__BSD_VISIBLE=1 manually to the EXTRA_CFLAGS in config.mk after I ran the configure script.

That worked. I'll further test the functionality.

[ehaupt]

From what I can tell, gbsplay works as expected. I was able to successfully play the nightmode.gbs sample.

[ehaupt]

Unfortunately dfa1f23 didn't solve the issue.

See: curl https://critical.ch/people/gbsplay-issue-105/typescript-noextraflags.txt

Adding -D__BSD_VISIBLE=1 to CFLAGS is still required.

See: curl https://critical.ch/people/gbsplay-issue-105/typescript-extraflags.txt

[mmitch]

I've tried to make a minimal broken example that we can include in our configure script to eg. detect if using sys/soundcard.h needs to have __BSD_VISIBLE set to true.

Unfortunately I could not get an example that does not compile. This compiles cleanly when just called as cc foo.c:

#include <sys/soundcard.h>
#include <stdio.h>
int main(int argc, char **argv) {
        snd_capabilities capabilites;  
        printf("%ld\n", sizeof(capabilites));
        return 0;
}

The snd_capabilites struct contains 5 u_longs and 1 u_short.
So it seems that our other compile flags somehow play into this, this needs further testing.

I have also found out that sys/soundcard.h contains multiple sound systems: The basic OSS /dev/dsp interface as well as a new FreeBSD AIO interface. Only the AIO interface uses the u_* types so theoretically we would be fine if the header file was split into two…
Apart from https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=de5df6489b6b425b8c626a7e524808ef6dc277ba I did not find any real documentation on how to use AIO yet. With more information we could write a FreeBSD specific AIO audio driver, just like DirectSound for Windows. But without fixing the compile problems this would not help us anyway.

[mmitch]

I have bisected the code and found the culprit:

Commit fad6a3e3b951de1f7def3 introduces the POSIX-enablement flags

GBSCFLAGS  := -D_XOPEN_SOURCE=500 -D_POSIX_C_SOURCE=200809L

which seem to disable __BSD_VISIBLE.

[mmitch]

We now have a CI pipeline that is able to reproduce this very bug and thus fails :wink: https://github.com/mmitch/gbsplay/actions?query=workflow%3A%22FreeBSD+Build%22

[ehaupt]

@mmitch Big thanks for sorting out the FreeBSD issue with GBSplay. Really appreciate your effort! Having a FreeBSD pipeline is an awesome bonus!

[mmitch]

@ehaupt Could you please test it? The fix has been merged to the master branch. The configure script should now automatically set __BSD_VISIBLE on FreeBSD.

[ehaupt]

@mmitch, I can confirm that e59ba36 fixes the issue. Thank you!

[mmitch]

I think we'll do another release then, even if it breaks our habit of multiple years going by between releases…