On Tue, Aug 30, 2011 at 10:34:40PM +0200, Matthias Kilian wrote:
> On Tue, Aug 30, 2011 at 02:20:55PM +0200, Landry Breuil wrote:
> > On Tue, Aug 30, 2011 at 01:35:56PM +0200, Donovan Watteau wrote:
> > > OK, thanks! So here's a new version, with the following changes:
> > > - Added SHARED_ONLY=Yes, regen'd PLIST and friends.
> > > - Added MAINTAINER=Me.
> > > - Fixed WANTLIB-flac and WANTLIB-wavpack.
> > > - Fixed HOSTCC/HOSTLD (which defaulted to gcc) and HOST_CFLAGS (which
> > > defaulted to their own flags). I think it should follow CC/LD and
> > > CFLAGS by default when not crossbuilding; I'll drop them a mail
> > > about that.
> > > - Removed CONFIG_WAV=y which is the default choice. I wanted to make
> > > it explicit but it doesn't seem to be the rule here.
> > > - Removed -Wredundant-decls which makes useless noise on OpenBSD
> > > because of some problems in system headers.
> > > - Added $OpenBSD$ in patches.
> > >
> > > If no one complains about the sndio backend, I'll ask cmus
> > > developers to merge it.
> >
> > Looks definitely good to me, i'd like to import it with another ok.
>
> With the special treatment for arm (.if ${MACHINE_ARCH} == "arm"),
> it doesn't packages on arm (missing vorbis.so or something).
>
> I commented all this conditional stuff, i.e. build it on arm with
>
> CONFIGURE_ARGS+= CONFIG_TREMOR=n \
> CONFIG_VORBIS=y
> LIB_DEPENDS+= audio/libvorbis
> WANTLIB-main+= ogg vorbis>=0 vorbisfile>=1
>
> and this builds, packages, and works (with AUDIODEVICE=aucat:localhost/0
> and remote-forwarding port 11025 from my armish back to my desktop
> (with aucat listining there on port 11025). Tested with mp3 and
> ogg.
>
> So please remove the conditional for arm (unless there's something
> I missed), and I'm *almost* ok with the port -- the install target
> machinery of the port is insane (just look at it), but that can be
> fixed after the import.
As for arm, it seems tremor is preffered to libvorbis because of floating
point sucking on arm and fixed point is better. Doesn't explain why it fails
to package, what is the ip/xxxx.so generated for tremor ?
configure doesn't play well with systrace :
checking for CFLAGS -std=gnu99 -pipe -Wall -Wshadow -Wcast-align
-Wpointer-arith -Wwrite-strings -Wundef -Wmissing-prototypes -Wextra
-Wno-sign-compare -Wformat-security.
.. systrace: deny user: landry, prog:
/usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid: 26741(0)[23944],
policy: /usr/bin/env, filters: 199, syscall: native-fswrite(5), filename:
/dev/null.gcda
yes
checking for CFLAGS -Wdeclaration-after-statement... systrace: deny user:
landry, prog: /usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid:
18288(0)[17202], policy:
/usr/bin/env, filters: 199, syscall: native-fswrite(5), filename:
/dev/null.gcda
yes
checking for CFLAGS -Wold-style-definition... systrace: deny user: landry,
prog: /usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid: 13262(0)[5648],
policy: /usr/bi
n/env, filters: 199, syscall: native-fswrite(5), filename: /dev/null.gcda
yes
checking for CFLAGS -Wno-pointer-sign... systrace: deny user: landry, prog:
/usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid: 8602(0)[22648],
policy: /usr/bin/env
, filters: 199, syscall: native-fswrite(5), filename: /dev/null.gcda
yes
checking for CFLAGS -Werror-implicit-function-declaration... systrace: deny
user: landry, prog: /usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid:
18738(0)[30314],
policy: /usr/bin/env, filters: 199, syscall: native-fswrite(5), filename:
/dev/null.gcda
yes
checking for CFLAGS -Wno-unused-parameter... systrace: deny user: landry, prog:
/usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid: 21620(0)[31620],
policy: /usr/bi
n/env, filters: 199, syscall: native-fswrite(5), filename: /dev/null.gcda
yes
checking if CC can generate dependency information... systrace: deny user:
landry, prog: /usr/lib/gcc-lib/amd64-unknown-openbsd5.0/4.2.1/cc1, pid:
16980(0)[12418], policy
: /usr/bin/env, filters: 199, syscall: native-fswrite(5), filename:
/dev/null.gcda
yes
I don't see where that /dev/null.gcda comes from..
And yes, the install stuff in the provided makefiles (well, all the
makefiles/configure are) is quite insane. It could be patched to use
our own INSTALL_ macros.
Landry
