Jan Stary writes:
> On Aug 28 10:21:41, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> > On Aug 27 11:21:58, h...@stare.cz wrote:
>> >> Testing on NetBSD 8.0, with the latest commits
>> >> to the new-build branch pulled in.
>> >
>> > With ./configure CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr
On Aug 28 10:21:41, m...@mansr.com wrote:
> Jan Stary writes:
>
> > On Aug 27 11:21:58, h...@stare.cz wrote:
> >> Testing on NetBSD 8.0, with the latest commits
> >> to the new-build branch pulled in.
> >
> > With ./configure CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib
> > the external lib
Jan Stary writes:
> On Aug 27 11:21:58, h...@stare.cz wrote:
>> Testing on NetBSD 8.0, with the latest commits
>> to the new-build branch pulled in.
>
> With ./configure CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib
> the external libraries are detected, with the exception of png:
>
> checki
Jan Stary writes:
> On Aug 27 19:50:52, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> > However, having a patch in a build system that is not even expected
>> > to apply cleanly is extremely fragile (beside being ugly).
>> > It depends on the precise GNU libtool version;
>>
>> I'm perfectly
On Aug 27 21:18:21, h...@stare.cz wrote:
> On Aug 27 19:50:52, m...@mansr.com wrote:
> > Jan Stary writes:
> >
> > > However, having a patch in a build system that is not even expected
> > > to apply cleanly is extremely fragile (beside being ugly).
> > > It depends on the precise GNU libtool ver
On Aug 27 11:21:58, h...@stare.cz wrote:
> Testing on NetBSD 8.0, with the latest commits
> to the new-build branch pulled in.
With ./configure CPPFLAGS=-I/usr/pkg/include LDFLAGS=-L/usr/pkg/lib
the external libraries are detected, with the exception of png:
checking for png.h... yes
checking for
On Aug 27 19:59:31, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> 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 /u
On Aug 27 19:50:52, m...@mansr.com wrote:
> Jan Stary writes:
>
> > However, having a patch in a build system that is not even expected
> > to apply cleanly is extremely fragile (beside being ugly).
> > It depends on the precise GNU libtool version;
>
> I'm perfectly happy to ignore it and let O
Jan Stary writes:
>> 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
>>
Jan Stary writes:
> However, having a patch in a build system that is not even expected
> to apply cleanly is extremely fragile (beside being ugly).
> It depends on the precise GNU libtool version;
I'm perfectly happy to ignore it and let OpenBSD users deal with it
however they please. You're t
> 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
On Aug 27 16:11:44, m...@mansr.com wrote:
> >>> > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib
> >>> > > > > -lpng [...]
> >>> > > > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox
> >>> > > > > -lpng [...]
> >>> > > > >
> >>> > > > > The first works, the se
Måns Rullgård writes:
> Jan Stary writes:
>
>> On Aug 27 11:40:48, h...@stare.cz wrote:
>>> On Aug 24 08:56:43, h...@stare.cz wrote:
>>> > On Aug 23 23:55:51, h...@stare.cz wrote:
>>> > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
>>> > > > > [...]
>>> > > > > cc [.
On Aug 27 16:10:12, h...@stare.cz wrote:
> On Aug 27 14:31:51, m...@mansr.com wrote:
> > Jan Stary writes:
> >
> > > On Aug 27 11:40:48, h...@stare.cz wrote:
> > >> On Aug 24 08:56:43, h...@stare.cz wrote:
> > >> > On Aug 23 23:55:51, h...@stare.cz wrote:
> > >> > > > > cc [...] -o .libs/sox sox.
On Aug 27 14:31:51, m...@mansr.com wrote:
> Jan Stary writes:
>
> > On Aug 27 11:40:48, h...@stare.cz wrote:
> >> On Aug 24 08:56:43, h...@stare.cz wrote:
> >> > On Aug 23 23:55:51, h...@stare.cz wrote:
> >> > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib
> >> > > > > -lpng
Jan Stary writes:
> On Aug 27 11:40:48, h...@stare.cz wrote:
>> On Aug 24 08:56:43, h...@stare.cz wrote:
>> > On Aug 23 23:55:51, h...@stare.cz wrote:
>> > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
>> > > > > [...]
>> > > > > cc [...] -o .libs/sox sox.o -L/usr/lo
On Aug 27 11:40:48, h...@stare.cz wrote:
> On Aug 24 08:56:43, h...@stare.cz wrote:
> > On Aug 23 23:55:51, h...@stare.cz wrote:
> > > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
> > > > > [...]
> > > > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lp
Jan Stary writes:
>> > 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 ch
On Aug 27 14:40:14, h...@stare.cz wrote:
> > > 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 th
> > 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 xst
Jan Stary writes:
> On Aug 27 12:08:02, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> > On Aug 24 08:56:43, h...@stare.cz wrote:
>> >> On Aug 23 23:55:51, h...@stare.cz wrote:
>> >> > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
>> >> > > > [...]
>> >> > > > cc [.
Jan Stary 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 a
On Aug 27 12:08:02, m...@mansr.com wrote:
> Jan Stary writes:
>
> > On Aug 24 08:56:43, h...@stare.cz wrote:
> >> On Aug 23 23:55:51, h...@stare.cz wrote:
> >> > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
> >> > > > [...]
> >> > > > cc [...] -o .libs/sox sox.o -L/us
Jan Stary writes:
>> >> Is there any other libtool?
>> >
>> > http://cvsweb.openbsd.org/src/usr.bin/libtool/
>> > http://man.openbsd.org/libtool
>> >
>> >Relative -L paths are put before absolute ones.
>> >This fixes many (but not all, unfortunately) issues
>> >when software links to
Jan Stary writes:
> On Aug 24 08:56:43, h...@stare.cz wrote:
>> On Aug 23 23:55:51, h...@stare.cz wrote:
>> > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
>> > > > [...]
>> > > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng
>> > > > [...]
>> > >
Jan Stary writes:
>> > Searching for -lsox in the -L path is also perfectly normal.
>> > As we now know, it is the order of the -L options
>> > introduced by GNU libtool that breaks it.
>> >
>> > Your "clean" VM is a special case in that it does not
>> > have a previous version installed (as oppo
Jan Stary writes:
> On Aug 24 13:19:46, h...@stare.cz wrote:
>> On Aug 24 12:04:11, m...@mansr.com wrote:
>> > Jan Stary writes:
>> >
>> > > We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH
>> > > into ./configure's environment produces a working link command;
>> > > passing CPP
> >> Is there any other libtool?
> >
> > http://cvsweb.openbsd.org/src/usr.bin/libtool/
> > http://man.openbsd.org/libtool
> >
> > Relative -L paths are put before absolute ones.
> > This fixes many (but not all, unfortunately) issues
> > when software links to libraries already install
> > Searching for -lsox in the -L path is also perfectly normal.
> > As we now know, it is the order of the -L options
> > introduced by GNU libtool that breaks it.
> >
> > Your "clean" VM is a special case in that it does not
> > have a previous version installed (as opposed to my screwed up,
> >
On Aug 24 08:56:43, h...@stare.cz wrote:
> On Aug 23 23:55:51, h...@stare.cz wrote:
> > > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
> > > > [...]
> > > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng
> > > > [...]
> > > >
> > > > The first works,
On Aug 24 13:19:46, h...@stare.cz wrote:
> On Aug 24 12:04:11, m...@mansr.com wrote:
> > Jan Stary writes:
> >
> > > We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH
> > > into ./configure's environment produces a working link command;
> > > passing CPPFLAGS and LDFLAGS to ./confi
Jan Stary writes:
> on NetBSD (where the build fails in other interesting ways)
Fixed.
--
Måns Rullgård
___
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
Jan Stary writes:
> On Aug 24 13:19:36, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> >> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng
>> >> > [...]
>> >> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng
>> >> > [...]
>> >> >
>> >> > The first w
On Aug 24 13:19:36, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...]
> >> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...]
> >> >
> >> > The first works, the second does not.
> >> > The only dif
Jan Stary writes:
> On Aug 24 13:27:00, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> >> It all works fine on my VM with this environment and no configure options:
>> >> AUTOCONF_VERSION=2.69
>> >> AUTOMAKE_VERSION=1.16
>> >> CC=cc
>> >> C_INCLUDE_PATH=/usr/local/include
>> >> LIBRARY_PATH=/
On Aug 24 13:27:00, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> It all works fine on my VM with this environment and no configure options:
> >> AUTOCONF_VERSION=2.69
> >> AUTOMAKE_VERSION=1.16
> >> CC=cc
> >> C_INCLUDE_PATH=/usr/local/include
> >> LIBRARY_PATH=/usr/local/lib
> >
> > I see yo
Jan Stary writes:
>> It all works fine on my VM with this environment and no configure options:
>> AUTOCONF_VERSION=2.69
>> AUTOMAKE_VERSION=1.16
>> CC=cc
>> C_INCLUDE_PATH=/usr/local/include
>> LIBRARY_PATH=/usr/local/lib
>
> I see you have changed the install instructions in the INSTALL file
>
Jan Stary writes:
>> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...]
>> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...]
>> >
>> > The first works, the second does not.
>> > The only difference between the two is the place
>> > where the extr
> It all works fine on my VM with this environment and no configure options:
> AUTOCONF_VERSION=2.69
> AUTOMAKE_VERSION=1.16
> CC=cc
> C_INCLUDE_PATH=/usr/local/include
> LIBRARY_PATH=/usr/local/lib
I see you have changed the install instructions in the INSTALL file
(slapping them onto the Aug 14
On Aug 24 12:04:11, m...@mansr.com wrote:
> Jan Stary writes:
>
> > We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH
> > into ./configure's environment produces a working link command;
> > passing CPPFLAGS and LDFLAGS to ./configure also used to produce
> > a working command, but
Jan Stary writes:
> We both know what it is: passing C_INCLUDE_PATH and LIBRARY_PATH
> into ./configure's environment produces a working link command;
> passing CPPFLAGS and LDFLAGS to ./configure also used to produce
> a working command, but now produces a failing link line;
> the position of -L
On Aug 23 23:55:51, h...@stare.cz wrote:
> > > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...]
> > > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...]
> > >
> > > The first works, the second does not.
> > > The only difference between the two is the
> > cc [...] -o .libs/sox sox.o -L./.libs -lsox -L/usr/local/lib -lpng [...]
> > cc [...] -o .libs/sox sox.o -L/usr/local/lib -L./.libs -lsox -lpng [...]
> >
> > The first works, the second does not.
> > The only difference between the two is the place
> > where the extra -L/usr/local/lib gets ad
> >> It's simple. The linker looks for libraries in
> >>
> >> 1. -L flags, in order
> >> 2. The LIBRARY_PATH environment variable
> >> 3. Compiled-in defaults, typically /usr/lib and /lib
> >>
> >> It is the responsibility of the system administrator to configure things
> >> in such a way that s
Jan Stary writes:
>> >> >> C_INCLUDE_PATH=/usr/local/include
>> >> >> LIBRARY_PATH=/usr/local/lib
>> >> >
>> >> > I never used any of these.
>> >> > Are they docummented anywhere?
>> >>
>> >> Many compilers/linkers support such environment variables. The gcc
>> >> manual documents them here:
>>
> >> >> C_INCLUDE_PATH=/usr/local/include
> >> >> LIBRARY_PATH=/usr/local/lib
> >> >
> >> > I never used any of these.
> >> > Are they docummented anywhere?
> >>
> >> Many compilers/linkers support such environment variables. The gcc
> >> manual documents them here:
> >> https://gcc.gnu.org/onlin
Jan Stary writes:
> On Aug 22 11:10:10, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> >> C_INCLUDE_PATH=/usr/local/include
>> >> LIBRARY_PATH=/usr/local/lib
>> >
>> > I never used any of these.
>> > Are they docummented anywhere?
>>
>> Many compilers/linkers support such environment variabl
On Aug 22 17:43:28, h...@stare.cz wrote:
> > > > Is it because of the _order_ of the -L options?
>
> Seems so:
>
> cc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes
> -Wstrict-prototypes -fstack-protector-strong -Wl,--as-needed -o .libs/sox
> sox.o -L/usr/local/lib -L./.libs -lsox
On Aug 22 17:35:45, h...@stare.cz wrote:
> On Aug 22 11:10:10, m...@mansr.com wrote:
> > Jan Stary writes:
> >
> > >> C_INCLUDE_PATH=/usr/local/include
> > >> LIBRARY_PATH=/usr/local/lib
> > >
> > > I never used any of these.
> > > Are they docummented anywhere?
> >
> > Many compilers/linkers su
> > > Is it because of the _order_ of the -L options?
Seems so:
cc -g -O2 -fstack-protector-strong -Wall -Wmissing-prototypes
-Wstrict-prototypes -fstack-protector-strong -Wl,--as-needed -o .libs/sox sox.o
-L/usr/local/lib -L./.libs -lsox -lpng -lltdl -lao -lgsm -lid3tag -lz -lmad
-lmp3lame -
On Aug 22 11:10:10, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> C_INCLUDE_PATH=/usr/local/include
> >> LIBRARY_PATH=/usr/local/lib
> >
> > I never used any of these.
> > Are they docummented anywhere?
>
> Many compilers/linkers support such environment variables. The gcc
> manual documents
Jan Stary writes:
>> C_INCLUDE_PATH=/usr/local/include
>> LIBRARY_PATH=/usr/local/lib
>
> I never used any of these.
> Are they docummented anywhere?
Many compilers/linkers support such environment variables. The gcc
manual documents them here:
https://gcc.gnu.org/onlinedocs/gcc/Environment-Var
On Aug 21 22:43:12, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> However, the build eventually fails with a linking error:
> >>
> >> /bin/sh ../libtool --tag=CC --mode=link cc -g -O2
> >> -fstack-protector-strong -Wall -Wmissing-prototypes -Wstrict-prototypes
> >> -avoid-version
Jan Stary writes:
>> However, the build eventually fails with a linking error:
>>
>> /bin/sh ../libtool --tag=CC --mode=link cc -g -O2 -fstack-protector-strong
>> -Wall -Wmissing-prototypes -Wstrict-prototypes -avoid-version -module
>> -L/usr/local/lib -fstack-protector-strong -Wl,--as-nee
> However, the build eventually fails with a linking error:
>
> /bin/sh ../libtool --tag=CC --mode=link cc -g -O2 -fstack-protector-strong
> -Wall -Wmissing-prototypes -Wstrict-prototypes -avoid-version -module
> -L/usr/local/lib -fstack-protector-strong -Wl,--as-needed -o sox sox.o
> lib
> > > checking for mt... mt
> > >
> > > LOL, what?
> > >
> > > checking if mt is a manifest tool... no
> > >
> > > That's a shame.
> >
> > It's something some systems require when linking. That's all I know.
>
> openbsd$ whatis mt
> mt, eject(1) - magnetic tape and removable media manipulati
On Aug 21 18:52:18, m...@mansr.com wrote:
> Jan Stary writes:
>
> > On Aug 21 18:08:27, m...@mansr.com wrote:
> >> Jan Stary writes:
> >>
> >> > On Aug 21 17:16:12, h...@stare.cz wrote:
> >> >> > checking for magic.h... no
> >> >> > checking for zlib.h... yes
> >> >> > checking for uncompress i
> Von: Jan Stary
> Gesendet: Freitag, 21. August 2020 16:05
> An: Måns Rullgård
> Cc: sox-devel@lists.sourceforge.net
> Betreff: Re: [SoX-devel] Build system cleanup
>
...
> > > checking for lpc10.h... no
> > >
> > > So why does it try to build lp
> >>> [$9 *], m4_argn([8], m4_shift2($@))) dnl OpenBSD m4 can't count
> >
> > Can you please give a minimal example of an m4 input
> > that demonstrates the problem? If something as fundamental
> > as counting the number of arguments is broken,
> > it needs fixing of course, instead of having
> > s
Jan Stary writes:
> On Aug 21 18:08:27, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> > On Aug 21 17:16:12, h...@stare.cz wrote:
>> >> > checking for magic.h... no
>> >> > checking for zlib.h... yes
>> >> > checking for uncompress in -lz... yes
>> >> > checking for png.h... no
>> >> > checki
On Aug 21 18:08:27, m...@mansr.com wrote:
> Jan Stary writes:
>
> > On Aug 21 17:16:12, h...@stare.cz wrote:
> >> > checking for magic.h... no
> >> > checking for zlib.h... yes
> >> > checking for uncompress in -lz... yes
> >> > checking for png.h... no
> >> > checking for mad.h... no
> >> > chec
Jan Stary writes:
> On Aug 21 17:16:12, h...@stare.cz wrote:
>> > checking for magic.h... no
>> > checking for zlib.h... yes
>> > checking for uncompress in -lz... yes
>> > checking for png.h... no
>> > checking for mad.h... no
>> > checking for id3tag.h... no
>> > checking for lame/lame.h... no
On Aug 21 17:16:12, h...@stare.cz wrote:
> > checking for magic.h... no
> > checking for zlib.h... yes
> > checking for uncompress in -lz... yes
> > checking for png.h... no
> > checking for mad.h... no
> > checking for id3tag.h... no
> > checking for lame/lame.h... no
> > checking for lame.h... no
> checking for magic.h... no
> checking for zlib.h... yes
> checking for uncompress in -lz... yes
> checking for png.h... no
> checking for mad.h... no
> checking for id3tag.h... no
> checking for lame/lame.h... no
> checking for lame.h... no
>
> $ pkg_info -L lame | grep .h$
> /us
Jan Stary writes:
>> > (I would still like to get rid of auto* anyway :-)
>>
>> Replacing it without losing anything is a huge amount of work. The
>> results can be great, but I don't want to spend the next month that
>> right now.
>
> Please have a look at https://github.com/janstary/sox
> whi
On Aug 21 14:49:53, h...@stare.cz wrote:
> On Aug 21 11:33:08, m...@mansr.com wrote:
> > Jan Stary writes:
> >
> > >> Testing on OpenBSD 6.7-current/amd64.
> > >> It eventually fails with lpc10.h not being found.
> > >> Full log below, comments inline.
> > >
> > > Trying agsin with ./configure --
> > (I would still like to get rid of auto* anyway :-)
>
> Replacing it without losing anything is a huge amount of work. The
> results can be great, but I don't want to spend the next month that
> right now.
Please have a look at https://github.com/janstary/sox
which uses a hand-written configu
Jan Stary writes:
> On Aug 21 11:33:08, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> >> Testing on OpenBSD 6.7-current/amd64.
>> >> It eventually fails with lpc10.h not being found.
>> >> Full log below, comments inline.
>> >
>> > Trying agsin with ./configure --prefix=$HOME --disable-lpc10
> > > Trying agsin with ./configure --prefix=$HOME --disable-lpc10
> > > to make it finosh without the lpc10 fail. Mysteriously,
> > > it fails with standard C funcrtions not bewing found
> >
> > I installed OpenBSD in a VM and noticed the same thing. It seems to
> > have something to do with lin
On Aug 21 11:33:08, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> Testing on OpenBSD 6.7-current/amd64.
> >> It eventually fails with lpc10.h not being found.
> >> Full log below, comments inline.
> >
> > Trying agsin with ./configure --prefix=$HOME --disable-lpc10
> > to make it finosh withou
Jan Stary writes:
> On Aug 21 11:28:50, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> >> checking for sys/soundcard.h... no
>> >> checking for sys/audioio.h... no
>> >> checking for sun/audioio.h... no
>> >>
>> >> Ha, I didn't have to --disable-sunaudio as before.
>> >
>> > Wait, this use
Jan Stary writes:
> On Aug 21 11:36:29, m...@mansr.com wrote:
>> Jan Stary writes:
>>
>> > ./configure: line 12902:
>> > `AX_APPEND_COMPILE_FLAGS(-fstack-protector-strong)'
>> >
>> > I am probably missing some other library of M4 macros.
>> > Can we please replace these with the obvious
>> >
>
On Aug 21 11:28:50, m...@mansr.com wrote:
> Jan Stary writes:
>
> >> checking for sys/soundcard.h... no
> >> checking for sys/audioio.h... no
> >> checking for sun/audioio.h... no
> >>
> >>Ha, I didn't have to --disable-sunaudio as before.
> >
> > Wait, this used to be --without-sunaudio.
>
On Aug 21 11:36:29, m...@mansr.com wrote:
> Jan Stary writes:
>
> > ./configure: line 12902: `AX_APPEND_COMPILE_FLAGS(-fstack-protector-strong)'
> >
> > I am probably missing some other library of M4 macros.
> > Can we please replace these with the obvious
> >
> > CFLAGS += ...
> > LDFLAGS +=
Jan Stary writes:
> Hi Måns,
>
> On Aug 19 21:40:36, m...@mansr.com wrote:
>> I have done some cleaning of the build system.
>
> thanks, the configure is much more readable now.
That was the general idea. Those new macros are a bit opaque, though.
> (I would still like to get rid of auto* anyw
Jan Stary writes:
> ./configure: line 12902: `AX_APPEND_COMPILE_FLAGS(-fstack-protector-strong)'
>
> I am probably missing some other library of M4 macros.
> Can we please replace these with the obvious
>
> CFLAGS += ...
> LDFLAGS += ...
>
> instead of using a library of macros to append an o
Jan Stary writes:
>> Testing on OpenBSD 6.7-current/amd64.
>> It eventually fails with lpc10.h not being found.
>> Full log below, comments inline.
>
> Trying agsin with ./configure --prefix=$HOME --disable-lpc10
> to make it finosh without the lpc10 fail. Mysteriously,
> it fails with standard C
Jan Stary writes:
>> checking for sys/soundcard.h... no
>> checking for sys/audioio.h... no
>> checking for sun/audioio.h... no
>>
>> Ha, I didn't have to --disable-sunaudio as before.
>
> Wait, this used to be --without-sunaudio.
> Aha, haven't read the commit message:
>
> The use of -
Testing on the latest macOS
Darwin mbstarecz.local 19.6.0 Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00
PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64 x86_64
u@h:W$ autoreconf -i
u@h:W$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environmen
> Testing on OpenBSD 6.7-current/amd64.
> It eventually fails with lpc10.h not being found.
> Full log below, comments inline.
Trying agsin with ./configure --prefix=$HOME --disable-lpc10
to make it finosh without the lpc10 fail. Mysteriously,
it fails with standard C funcrtions not bewing found
(
> checking for sys/soundcard.h... no
> checking for sys/audioio.h... no
> checking for sun/audioio.h... no
>
> Ha, I didn't have to --disable-sunaudio as before.
Wait, this used to be --without-sunaudio.
Aha, haven't read the commit message:
The use of --enable and --with flags has bee
On Aug 20 22:22:18, m...@mansr.com wrote:
> Wolfgang Stoeggl via SoX-devel writes:
>
> > Hi,
> > lpc10.h is not found in the new-build branch during make, when no external
> > lpc10 is installed on the system and the internal lpc10/lpc10.h should be
> > included.
> > - Error:
> > lpc10.c:22:10: f
OK, it is fixed.
Am Donnerstag, 20. August 2020, 23:22:19 MESZ hat Måns Rullgård
Folgendes geschrieben:
Wolfgang Stoeggl via SoX-devel writes:
> Hi,
> lpc10.h is not found in the new-build branch during make, when no external
> lpc10 is installed on the system and the internal lpc10
Wolfgang Stoeggl via SoX-devel writes:
> Hi,
> lpc10.h is not found in the new-build branch during make, when no external
> lpc10 is installed on the system and the internal lpc10/lpc10.h should be
> included.
> - Error:
> lpc10.c:22:10: fatal error: lpc10.h: No such file or directory
> 22 | #inc
Hi,
lpc10.h is not found in the new-build branch during make, when no external
lpc10 is installed on the system and the internal lpc10/lpc10.h should be
included.
- Error:
lpc10.c:22:10: fatal error: lpc10.h: No such file or directory
22 | #include
- How to reproduce:git checkout new-build
au
85 matches
Mail list logo
