Jan Stary <h...@stare.cz> writes: >> The result is in the 'new-build' git branch. >> I'd appreciate if people, especially on BSD, >> could give it a try and report any problems. > > Testing on NetBSD 8.0, with the latest commits > to the new-build branch pulled in. > > It seems that the recent commit regarding audioio.h and soundcard.h, > while it makes the build not fail, also mis-detects NetBSD's output > audio driver. The result is a sox that builds but cannot play; > full log below, comments inline. > > Jan > > It's cc (nb2 20180327) 5.5.0, with the following packages > as installed by NetBSD's packaging system:
[...] > checking for strdup... yes > > Not specific to NetBSD of course, but why are we running these > tests (taking strdup as a random example)? Is there a POSIX > system without strdup? And if we miss strdup, then what? > With that configure.ac line changed to check for xstrdup instead, > this will just become > > checking for xstrdup... no > > but everyting follows as before. Which means we have checked for > a function (via AC_CHECK_FUNCS), found out it does not exist, > and ignored the result. What is that for? I already explained this about five times. > checking for popen... yes > checking for vsnprintf... yes > checking for gettimeofday... yes > checking for mkstemp... yes > checking for fmemopen... yes > checking for sigaction... yes > checking for library containing pow... -lm > checking for library containing lrint... none required > > This seems to be the same error as on OpenBSD: > > $ nm /lib/libc.so | grep -Fw lrint > $ nm /lib/libm.so | grep -Fw lrint > 000000000000f4f9 T lrint > > So -lm _is_ required for lrint() - it works by accident, > because -lm is pulled in anyway to have pow(). If the text said "no additional libraries required", would you be happy? That's what it actually means, and I don't consider it a bug. It's checking if those functions exist and if they require -lm. They're now standard C99, so this can probably be safely simplified to simply check whether -lm is required at all. > checking for magic.h... yes > checking for magic_open in -lmagic... yes > > That's /usr/include/magic.h and /usr/lib/libmagic.so, > found in the default paths. Is that a problem? > checking for zlib.h... yes > checking for uncompress in -lz... yes > > /usr/include/zlib.h > /usr/lib/libz.so Yes, and? > checking for png.h... no > > On NetBSD, the third-party packages are installed into /usr/pkg > - I will run a separate test with the external libraries. If the compiler doesn't look there by default, some environment variables will have to be set. > checking for id3tag.h... no > checking for gsm/gsm.h... no > checking for gsm.h... no > checking for opencore-amrnb/interf_dec.h... no > checking for opencore-amrwb/dec_if.h... no > checking for vo-amrwbenc/enc_if.h... no > checking for flac... yes > > Found in /usr/pkg via pkg-config: > > $ pkg-config --cflags --libs flac > -I/usr/pkg/include -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -lFLAC Is this a problem? > checking for sys/soundcard.h... yes > > On NetBSD, sys/soundcard.h says > > This is an OSS (Linux) audio emulator. > Use the Native NetBSD API for developing new code, > and this only for compiling Linux programs. > > The check is > > SOX_FMT_HEADERS([oss], [sys/soundcard.h], [SOUND_MIXER_MUTE], > [], [devices]) > > so at least we correctly recognize this as OSS emulation. > But the check does not work universaly: NetBSD has > /usr/include/sys/soundcard.h -> ../soundcard.h, but e.g. > OpenBSD only has /usr/include/soundcard.h (same code though). > Apparently, the name makes a difference: > a test for "sys/soundcard.h" will fail on OpenBSD. > > checking whether SOUND_MIXER_MUTE is declared... no > > Why SOUND_MIXER_MUTE, specificaly, out of all the others? > For example, SOUND_MIXER_INFO is declared, which would > make the oss emulation detected (not saying this is > the correct test). > > Lastly, oss requires a library to be linked: > https://netbsd.gw.com/cgi-bin/man-cgi?ossaudio > That would be /usr/lib/libossaudio.so - I believe a recent > commit has concluded that oss does not require any library > (being a bunch of defined ioctls); on NetBSD, it maybe does. > > $ nm /usr/lib/libossaudio.so | grep oss > 0000000000001f60 T _oss_ioctl Real OSS does _not_ need a library. That is _only_ used for the incomplete emulation that we don't want. The test is chosen such that it passes on Linux, FreeBSD, and Solaris while failing on NetBSD and OpenBSD. > checking for sndio.h... no > > checking for sys/audioio.h... yes > > This seems to be NetBSD's native audio interface. > https://netbsd.gw.com/cgi-bin/man-cgi?audio > It's what the NetBSD port of SoX uses: > http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/audio/sox/ > > checking whether AUDIO_HWFEATURE_DUPLEX is declared... no > > ... but we miss that, because of this. > It seems NetBSD's audio system came from Sun audio > (/usr/pkg/bin/sox reports AUDIO DEVICE DRIVERS: sunau), > but it's not quite the same; in particular, > AUDIO_HWFEATURE_DUPLEX is not defined. Already fixed. > Maybe we can backport some patches from the NetBSD port. > http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/audio/sox/patches/ I'll take a look. > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 > -fstack-protector-strong -Wall -Wmissing-prototypes -Wstrict-prototypes > -fopenmp -Wl,--as-needed -o sox sox.o libsox.la -lm > libtool: link: gcc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes > -Wstrict-prototypes -fopenmp -Wl,--as-needed -o .libs/sox sox.o > ./.libs/libsox.so -L/usr/pkg/lib -lmagic /usr/pkg/lib/libFLAC.so > /usr/pkg/lib/libopusfile.so /usr/pkg/lib/libopus.so > /usr/pkg/lib/libvorbisenc.so /usr/pkg/lib/libvorbisfile.so > /usr/pkg/lib/libvorbis.so /usr/pkg/lib/libogg.so -lm -fopenmp -Wl,-rpath > -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/pkg/lib > > Full path of .libs/libsox.so and the external libraries, > -lm -lmagic for the system libraries. > Not sure how /usr/local/lib got there > - /usr/local doesn't even exist here. You used the (default) /usr/local installation prefix. An rpath entry for this is added to the linked executable so the shared library will be found once installed. This is reasonable. -- Måns Rullgård _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
