Re: Build system cleanup

["Måns Rullgård" <mans@mansr.com>]

Jan Stary <hans@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