From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Valtteri Vuorikoski Newsgroups: gmane.emacs.bugs Subject: bug#64698: 29.0.92; on netbsd 9.3, gmake and "gmake bootstrap" fail to proceed Date: Sat, 22 Jul 2023 20:08:42 +0300 Message-ID: References: <87sf9l5xj9.fsf@yahoo.com> <83edl578r7.fsf@gnu.org> <202307190310.36J3ADWp017577@sdf.org> <837cqw5bho.fsf@gnu.org> <838rbb42ab.fsf@gnu.org> <83a5vq36kk.fsf@gnu.org> <837cqt1q7m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22175"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: NeoMutt/20230517-193-0143df-dirty Cc: luangruo@yahoo.com, van.ly@sdf.org, eggert@cs.ucla.edu, 64698@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 22 19:10:20 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qNG7Y-0005VG-0O for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jul 2023 19:10:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qNG7I-0004pL-Kr; Sat, 22 Jul 2023 13:10:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qNG7H-0004ox-5F for bug-gnu-emacs@gnu.org; Sat, 22 Jul 2023 13:10:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qNG7G-0000t7-TY for bug-gnu-emacs@gnu.org; Sat, 22 Jul 2023 13:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qNG7G-0004Nn-FW for bug-gnu-emacs@gnu.org; Sat, 22 Jul 2023 13:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Valtteri Vuorikoski Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jul 2023 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64698 X-GNU-PR-Package: emacs Original-Received: via spool by 64698-submit@debbugs.gnu.org id=B64698.169004575516790 (code B ref 64698); Sat, 22 Jul 2023 17:10:02 +0000 Original-Received: (at 64698) by debbugs.gnu.org; 22 Jul 2023 17:09:15 +0000 Original-Received: from localhost ([127.0.0.1]:37521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNG6V-0004Mj-6t for submit@debbugs.gnu.org; Sat, 22 Jul 2023 13:09:15 -0400 Original-Received: from jkusti.notcom.org ([118.27.113.153]:55872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNG6T-0004MY-8V for 64698@debbugs.gnu.org; Sat, 22 Jul 2023 13:09:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=notcom.org; s=jk; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vRxD9l6pPGPnvij//GvkXM9NzLx80gL1HxVFNyi0ovk=; t=1690045753; x=1690909753; b=MAXyR3OkTUuq2He8sQgVEwcC9H8Bh/x98xoie4ctLylX+MMNqaRY6cLNbi0cKdw0EZFqG7mCeKa vhIOR2xTSEl30p8SJF1S/o3u06xeLBZmwkKpGZviHpak6MV+AqqBNW64AhU8Bu5Frg5hf6ZKi81BE kWyok5WblcTOOqW7HHBubqE138ySu8ShR6x6bgRD3KDq7WsqMU6+ejyv/CdY0uxlZayvhVVMi61fD LBd6ASEZ2v0yjZ1A7aQ6EySBXmI+LXICeQH39WnTMCoWOzR2/dX2oZGcefmBe5Lo6g+b8yjK5PPRB Jg4+TppWIIFmo9pC617ecLI51STjPhrC7YeA==; Original-Received: from submission.internal (id=9cdceae8c7b5bf2d4c2c643b5341fa4197f0c084) by jkusti.notcom.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.x) (envelope-from ) id 1qNG66-003WLw-Jq; Sat, 22 Jul 2023 17:08:50 +0000 Original-Received: from a10d750d756b015054aa81d63d047a232e64e839 by sendhost.internal with local (Exim 4.x) (envelope-from ) id 1qNG5y-006hcc-Ot; Sat, 22 Jul 2023 20:08:42 +0300 Content-Disposition: inline In-Reply-To: <837cqt1q7m.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265834 Archived-At: On Fri, Jul 21, 2023 at 02:03:41PM +0300, Eli Zaretskii wrote: > > If you want to apply it for -30, this basically implements the > > suggestion that was already dnl'd in configure.ac. Emacs will end up > > using ossaudio even if the alsa-lib pkgsrc package is installed. > > Thanks. The comments say "NetBSD", but I don't quite see where this > change affects only the *BSD systems, let alone NetBSD alone. Maybe > we should add that condition explicitly? I'd hate to break some other > system while fixing NetBSD. Based on an investigation of source trees, libossaudio exists on NetBSD and OpenBSD. Comments (diff below) have been updated to reflect this. FreeBSD (going back from current to 4.x) and DragonflyBSD (from current to 1.2) don't have it. configure.ac --with-sound=yes cannot have picked bsd-ossaudio if -lossaudio is not found, so this change should not have any effect on FreeBSD/DragonflyBSD: LIBSOUND has always ended up empty on those and hence the LIBSOUND=-lossaudio test will always fail. Meanwhile OpenBSD appears to have behaved the same as NetBSD: use ALSA if it exists, otherwise ossaudio. OpenBSD binary packages seem to be built with --without-sound (https://github.com/openbsd/ports/blob/master/editors/emacs/Makefile) so this change won't affect their package builds in any case. Updated diff (comment update only): --- configure.ac.old 2023-07-22 16:27:51.312652423 +0000 +++ configure.ac 2023-07-22 16:30:58.860198891 +0000 @@ -1793,12 +1793,14 @@ AC_MSG_ERROR([OSS sound support requested but not found.]) if test "${with_sound}" = "bsd-ossaudio" || test "${with_sound}" = "yes"; then - # Emulation library used on NetBSD. + # OSS emulation library used on NetBSD and OpenBSD. AC_CHECK_LIB([ossaudio], [_oss_ioctl], [LIBSOUND=-lossaudio], [LIBSOUND=]) test "${with_sound}" = "bsd-ossaudio" && test -z "$LIBSOUND" && \ AC_MSG_ERROR([bsd-ossaudio sound support requested but not found.]) - dnl FIXME? If we did find ossaudio, should we set with_sound=bsd-ossaudio? - dnl Traditionally, we go on to check for alsa too. Does that make sense? + # On {Net,Open}BSD use the system audio library instead of potentially switching + # to ALSA below, as ALSA on these appears to just wrap system libraries. + test "${with_sound}" = "yes" && test "$LIBSOUND" = "-lossaudio" && \ + with_sound="bsd-ossaudio" fi AC_SUBST([LIBSOUND]) > > People who want alsa should be able to still get it with > > --with-sound=alsa. > > This should probably be mentioned in NEWS, then. How about this for a NEWS entry: ** Emacs now always uses the ossaudio library for sound output on NetBSD and OpenBSD. Previously configure used ALSA libraries if installed on the system when --with-sound was set to "yes" (the default), with fallback to libossaudio. The libossaudio library included with the base system is now used even if ALSA is found to avoid relying on external packages and to resolve potential incompatibilities between Linux and BSD versions of ALSA. Set --with-sound=alsa to build with ALSA on these operating systems instead. re Van's comment on the native sound API: it's true that ossaudio(3) recommends using the native (lower-level?) API for new development, but someone would have to implement support for it. Since there have apparently been few complains wrt ossaudio, while ALSA on BSD on the other hand seems slightly problematic (and is not the native API either, but a wrapper similar to libossaudio), carrying on with ossaudio seems reasonable from a development-effort perspective. But I can't speak about the end-user perspective, since I don't have any BSD boxen that are likely to output audio. -Valtteri