GNU bug report logs -
#64698
29.0.92; on netbsd 9.3, gmake and "gmake bootstrap" fail to proceed
Previous Next
Reported by: Van Ly <van.ly <at> sdf.org>
Date: Tue, 18 Jul 2023 09:38:02 UTC
Severity: normal
Found in version 29.0.92
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64698 in the body.
You can then email your comments to 64698 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Tue, 18 Jul 2023 09:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Van Ly <van.ly <at> sdf.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 18 Jul 2023 09:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On netbsd 9.3, the following configure options will let gmake build to completion.
> ./configure --without-all --without-x --without-compress-install --localstatedir=/var --disable-autodepend --prefix=/path/to/emacs-29.0.92 --build=x86_64--netbsd --host=x86_64--netbsd --enable-option-checking=yes --without-pop --without-mailutils 'CFLAGS=-O2 -D_FORTIFY_SOURCE=2 -I/usr/include' 'CPPFLAGS=-DTERMINFO -I/usr/include' 'LDFLAGS=-L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib'
The following steps in the build process fail after unpacking the source distribution files.
> $ sh ./autogen.sh
> $ ./configure --without-x
> $ gmake
>
> ...
>
> ***
> *** "make all" failed with exit status 2.
> ***
> *** You could try to:
> *** - run "make bootstrap", which might fix the problem
> *** - run "make V=1", which displays the full commands invoked by make,
> *** to further investigate the problem
> ***
> gmake[1]: *** [Makefile:414: advice-on-failure] Error 2
> gmake[1]: Leaving directory '/usr/X/23/src/emacs/emacs-29.0.92'
> gmake: *** [Makefile:370: all] Error 2
>
> $ gmake bootstrap
>
> ...
>
> ***
> *** "make bootstrap" failed with exit status 2.
> ***
> *** You could try to:
> *** - run "make extraclean" and run "make" again (or, equivalently, run
> *** "make bootstrap configure=default"), to rebuild Emacs with the
> *** default configuration options, which might fix the problem
> *** - run "git clean -fdx" and run "make bootstrap" again, which might
> *** fix the problem if "make bootstrap configure=default" did not
> *** !BEWARE! "git clean -fdx" deletes all files that are not under
> *** !BEWARE! version control, which means that all changes to such
> *** !BEWARE! files will be lost and cannot be restored later
> *** - run "make V=1", which displays the full commands invoked by make,
> *** to further investigate the problem
> *** - report the problem and ask for help by sending an email to
> *** bug-gnu-emacs <at> gnu.org, mentioning at least the build error
> *** message, the platform, and the repository revision displayed by
> *** "git rev-parse HEAD"
> ***
> gmake[1]: *** [Makefile:414: advice-on-failure] Error 2
> gmake[1]: Leaving directory '/usr/X/23/src/emacs/emacs-29.0.92'
> gmake: *** [Makefile:1246: bootstrap] Error 2
[bug-report.text (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Tue, 18 Jul 2023 10:24:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 64698 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> On netbsd 9.3, the following configure options will let gmake build to
> completion.
[...]
You have ommitted the compiler and Make output from the compilation,
leaving only the troubleshooting instructions printed by the Makefile
after it failed.
Please include complete build output, or at least the actual error
itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Tue, 18 Jul 2023 11:35:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 64698 <at> debbugs.gnu.org (full text, mbox):
> Cc: 64698 <at> debbugs.gnu.org
> Date: Tue, 18 Jul 2023 18:22:50 +0800
> From: Po Lu via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Van Ly <van.ly <at> sdf.org> writes:
>
> > On netbsd 9.3, the following configure options will let gmake build to
> > completion.
>
> [...]
>
> You have ommitted the compiler and Make output from the compilation,
> leaving only the troubleshooting instructions printed by the Makefile
> after it failed.
>
> Please include complete build output, or at least the actual error
> itself.
Yes, please.
Also, please tell what is the last commit on the emacs-29 branch that
you used to build (assuming you have built the emacs-29 branch of the
Emacs Git repository; if not, please tell what did you sue for the
sources).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Wed, 19 Jul 2023 03:11:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 64698 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Date: Tue, 18 Jul 2023 14:35:08 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: van.ly <at> sdf.org, 64698 <at> debbugs.gnu.org
>
> > Cc: 64698 <at> debbugs.gnu.org
> > Date: Tue, 18 Jul 2023 18:22:50 +0800
> > From: Po Lu via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > Van Ly <van.ly <at> sdf.org> writes:
> >
> > > On netbsd 9.3, the following configure options will let gmake build to
> > > completion.
> >
> > [...]
> >
> > You have ommitted the compiler and Make output from the compilation,
> > leaving only the troubleshooting instructions printed by the Makefile
> > after it failed.
> >
> > Please include complete build output, or at least the actual error
> > itself.
>
> Yes, please.
>
> Also, please tell what is the last commit on the emacs-29 branch that
> you used to build (assuming you have built the emacs-29 branch of the
> Emacs Git repository; if not, please tell what did you sue for the
> sources).
>
The sour was unpacked from a complete emacs-29.0.92.tar.xz file and
the sig detail is listed as part of the complete build output in the
attached file. Attempting a git log command gives,
$ git log
fatal: not a git repository (or any of the parent directories): .git
The xz file would have come from the gnu website for download announced on an emacs feed.
The tooling I believe used was as follows,
$ gmake -v
GNU Make 4.3
Built for x86_64--netbsd
$ gcc --version
gcc (GCC) 10.3.0
Here is the full build output. The fly in the soup is I interrupted
the first unadultrated configure run since I recollected I didn't want X
and ran './configure --without-x. That occurs at line 270 of 1985.
[complete-build-output.text (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Wed, 19 Jul 2023 12:31:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 64698 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 19 Jul 2023 03:10:13 GMT
> From: Van Ly <van.ly <at> sdf.org>
> Cc: luangruo <at> yahoo.com, 64698 <at> debbugs.gnu.org
>
> sound.c: In function ‘alsa_write’:
> sound.c:1150:28: error: ‘ESTRPIPE’ undeclared (first use in this function); did you mean ‘ESPIPE’?
> 1150 | else if (err == -ESTRPIPE)
> | ^~~~~~~~
> | ESPIPE
> sound.c:1150:28: note: each undeclared identifier is reported only once for each function it appears in
> gmake[3]: *** [Makefile:424: sound.o] Error 1
Thanks.
Paul, any ideas? Do we just condition that by ESTRPIPE being defined?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Wed, 19 Jul 2023 21:03:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 64698 <at> debbugs.gnu.org (full text, mbox):
On 2023-07-19 05:31, Eli Zaretskii wrote:
> Paul, any ideas? Do we just condition that by ESTRPIPE being defined?
The right way to do it would be to look at the NetBSD source code and
see how their ALSA libraries deal with the situation. Whoever's
reporting the problem would be in a better position to investigate this.
In the meantime, conditioning it as you suggest will get Emacs to
compile (albeit there may be problems if that unusual situation occurs).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Thu, 20 Jul 2023 04:48:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 64698 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 19 Jul 2023 14:01:54 -0700
> Cc: luangruo <at> yahoo.com, 64698 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
>
> On 2023-07-19 05:31, Eli Zaretskii wrote:
> > Paul, any ideas? Do we just condition that by ESTRPIPE being defined?
>
> The right way to do it would be to look at the NetBSD source code and
> see how their ALSA libraries deal with the situation. Whoever's
> reporting the problem would be in a better position to investigate this.
Thanks.
Valtteri, could you perhaps look into this? Also, I'd be interested
to know why you didn't bump into this problem in your builds.
> In the meantime, conditioning it as you suggest will get Emacs to
> compile (albeit there may be problems if that unusual situation occurs).
OK, will do if no better ideas emerge soon.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Thu, 20 Jul 2023 10:14:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 64698 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 20, 2023 at 07:47:40AM +0300, Eli Zaretskii wrote:
> > On 2023-07-19 05:31, Eli Zaretskii wrote:
> > > Paul, any ideas? Do we just condition that by ESTRPIPE being defined?
> >
> > The right way to do it would be to look at the NetBSD source code and
> > see how their ALSA libraries deal with the situation. Whoever's
> > reporting the problem would be in a better position to investigate this.
>
> Thanks.
>
> Valtteri, could you perhaps look into this? Also, I'd be interested
> to know why you didn't bump into this problem in your builds.
I've been building with --without-sound, and didn't have the ALSA
library package installed either.
I don't have a machine where I could actually test whether sound comes
out, but the alsa-lib package in NetBSD pkgsrc includes an internal
type_compat.h header that does this:
#ifndef ESTRPIPE
#define ESTRPIPE EPIPE
#endif
Building emacs with sound enabled but alsa-lib _not_ installed seems
to work (= compiles and starts) by using the system OSS library. Since
Emacs's audio needs are modest, it may be better to use "bsd-ossaudio"
on NetBSD if --with-sound=yes. AFAICT "ALSA" on NetBSD is just a proxy
for the native audio system anyway.
The other option is to try and use ALSA if --with-sound=yes, but
#ifdef out the ESTRPIPE branch if ESTRPIPE is not defined.
Personally I'd go with the default-to-ossaudio option, since pulling in
alsa libraries introduces a pkgsrc dependency into the binary and doesn't
seem like it provides a lot of benefit. I'm not quite sure what's the
best way to convince configure.ac to act like this, but I can test
patches at least on a compiles/doesn't-compile level.
-Valtteri
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Thu, 20 Jul 2023 16:13:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 64698 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 20 Jul 2023 13:13:12 +0300
> From: Valtteri Vuorikoski <vuori <at> notcom.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, van.ly <at> sdf.org, luangruo <at> yahoo.com,
> 64698 <at> debbugs.gnu.org
>
> On Thu, Jul 20, 2023 at 07:47:40AM +0300, Eli Zaretskii wrote:
> > Valtteri, could you perhaps look into this? Also, I'd be interested
> > to know why you didn't bump into this problem in your builds.
>
> I've been building with --without-sound, and didn't have the ALSA
> library package installed either.
>
> I don't have a machine where I could actually test whether sound comes
> out, but the alsa-lib package in NetBSD pkgsrc includes an internal
> type_compat.h header that does this:
>
> #ifndef ESTRPIPE
> #define ESTRPIPE EPIPE
> #endif
>
> Building emacs with sound enabled but alsa-lib _not_ installed seems
> to work (= compiles and starts) by using the system OSS library. Since
> Emacs's audio needs are modest, it may be better to use "bsd-ossaudio"
> on NetBSD if --with-sound=yes. AFAICT "ALSA" on NetBSD is just a proxy
> for the native audio system anyway.
>
> The other option is to try and use ALSA if --with-sound=yes, but
> #ifdef out the ESTRPIPE branch if ESTRPIPE is not defined.
>
> Personally I'd go with the default-to-ossaudio option, since pulling in
> alsa libraries introduces a pkgsrc dependency into the binary and doesn't
> seem like it provides a lot of benefit. I'm not quite sure what's the
> best way to convince configure.ac to act like this, but I can test
> patches at least on a compiles/doesn't-compile level.
Thanks. I went with the #ifdef approach on the release branch, since
it's simpler and therefore safer.
Patches are welcome for preferring bsd-ossaudio on NetBSD.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Fri, 21 Jul 2023 10:15:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 64698 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 20, 2023 at 07:12:43PM +0300, Eli Zaretskii wrote:
> > Building emacs with sound enabled but alsa-lib _not_ installed seems
> > to work (= compiles and starts) by using the system OSS library. Since
> > Emacs's audio needs are modest, it may be better to use "bsd-ossaudio"
> > on NetBSD if --with-sound=yes. AFAICT "ALSA" on NetBSD is just a proxy
> > for the native audio system anyway.
> >
> > The other option is to try and use ALSA if --with-sound=yes, but
> > #ifdef out the ESTRPIPE branch if ESTRPIPE is not defined.
> >
> > Personally I'd go with the default-to-ossaudio option, since pulling in
> > alsa libraries introduces a pkgsrc dependency into the binary and doesn't
> > seem like it provides a lot of benefit. I'm not quite sure what's the
> > best way to convince configure.ac to act like this, but I can test
> > patches at least on a compiles/doesn't-compile level.
>
> Thanks. I went with the #ifdef approach on the release branch, since
> it's simpler and therefore safer.
>
> Patches are welcome for preferring bsd-ossaudio on NetBSD.
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.
--- a/configure.ac
+++ b/configure.ac
@@ -1797,8 +1797,10 @@ AC_DEFUN
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 NetBSD use the system audio library instead of potentially switching
+ # to ALSA later on, as ALSA on NetBSD appears to just wrap OSS.
+ test "${with_sound}" = "yes" && test "$LIBSOUND" = "-lossaudio" && \
+ with_sound="bsd-ossaudio"
fi
AC_SUBST([LIBSOUND])
The emacs28 pkgsrc package doesn't set any sound-related configure
flags. I assume they're building binary packages on an alsa-free
system and have been happy with the result (= -lossaudio is used
because no alsa).
People who want alsa should be able to still get it with
--with-sound=alsa.
- Valtteri
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Fri, 21 Jul 2023 11:04:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 64698 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 21 Jul 2023 13:13:36 +0300
> From: Valtteri Vuorikoski <vuori <at> notcom.org>
> Cc: eggert <at> cs.ucla.edu, van.ly <at> sdf.org, luangruo <at> yahoo.com,
> 64698 <at> debbugs.gnu.org
>
> > Patches are welcome for preferring bsd-ossaudio on NetBSD.
>
> 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.
> People who want alsa should be able to still get it with
> --with-sound=alsa.
This should probably be mentioned in NEWS, then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Fri, 21 Jul 2023 12:13:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 64698 <at> debbugs.gnu.org (full text, mbox):
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.
>
> > People who want alsa should be able to still get it with
> > --with-sound=alsa.
>
> This should probably be mentioned in NEWS, then.
The existing comment a few lines above indicates that -lossaudio is a
NetBSD thing, but I can't speak on how accurate that statement is. I'll
investigate and update the patch (and NEWS) as approriate.
-Valtteri
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Fri, 21 Jul 2023 12:46:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 64698 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 21 Jul 2023 15:12:27 +0300
> From: Valtteri Vuorikoski <vuori <at> notcom.org>
> Cc: eggert <at> cs.ucla.edu, van.ly <at> sdf.org, luangruo <at> yahoo.com,
> 64698 <at> debbugs.gnu.org
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
>
> The existing comment a few lines above indicates that -lossaudio is a
> NetBSD thing, but I can't speak on how accurate that statement is. I'll
> investigate and update the patch (and NEWS) as approriate.
>
NetBSD's ossaudio(3) manpage says to use the native interface for new programs.
https://man.netbsd.org/ossaudio.3
https://man.netbsd.org/audio.4
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#64698
; Package
emacs
.
(Sat, 22 Jul 2023 17:10:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 64698 <at> debbugs.gnu.org (full text, mbox):
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
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Wed, 26 Jul 2023 14:06:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Van Ly <van.ly <at> sdf.org>
:
bug acknowledged by developer.
(Wed, 26 Jul 2023 14:06:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 64698-done <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 22 Jul 2023 20:08:42 +0300
> From: Valtteri Vuorikoski <vuori <at> notcom.org>
> Cc: eggert <at> cs.ucla.edu, van.ly <at> sdf.org, luangruo <at> yahoo.com,
> 64698 <at> debbugs.gnu.org
>
> 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):
Thanks, installed on the master branch, and closing the bug.
> > This should probably be mentioned in NEWS, then.
>
> How about this for a NEWS entry:
Thanks, I used it with a few minor changes.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 24 Aug 2023 11:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.