Uraeus checked in the bashism patch, which broke a lot of stuff that
has hopefully been cleaned up.

I rewrote some of the netbsd patch.

#!/usr/bin/perl is correct, it should not be changed.  Please fix your
perl installation.

From talking to people on #netbsd, I do not understand why the siginfo
change is necessary.  Apparently netbsd has siginfo support.  Anyway,
gst-launch.c now checks, and falls back on sa_handler.

I also don't understand the G_HAVE_ISO_VARARGS problem.  This occurs a
number of times in GStreamer; I don't see why it should be specific to
parse.l.

Same for grammar.y.

Could you provide build logs that show compilation failures for these?

First at all, please tell me *what* the bash patch broke. The autogen
scripts worked find here, on a /bin/sh absolutely compatible with
POSIX 1003.2 and 1003.2a. Unless your system's shell that claims to
be /bin/sh is broken, everything should work. I checked out a fresh
source tree from CVS, and it seems at least my changes are still in.

Then to the '/usr/bin/env perl' trick (see 'man perlrun'). My perl
installation is *not* broken. Perl on NetBSD is installed as
/usr/pkg/bin/perl. It is *not* in the base system, as it isn't on
many commercial unices. If you want a real solution, you have to
use AC_PATH_PROG() in configure.in and put that into the interpreter
line. Unix != Linux, in case you thought. You will find tons of
perl interpreters in /usr/opt, /opt, /usr/local and the like.

To the sighandler: I don't know who you asked and *what* you asked,
but on NetBSD-1.6 (the stable branch) and all older systems,
there is no *siginfo* interface *YET*. NetBSD-current may have that,
but it's irrelevant for users what the kernel hackers have. That
might be added for 1.7 in the future, but not now. An excerpt from
the sigaction(2) manpage:

"For POSIX compliance, the sa_handler is declared to be (void *)(int))
and the above handler will need to be casted to that type.  Future 
versions of NetBSD will replace the sigcontext interface with the
siginfo interface."

G_HAVE_ISO_VARARGS is undefined in glib2's glibconfig.h file, if the
compiler is gcc-2.95.x. The code:

#if __GNUC__ == 2 && __GNUC_MINOR__ == 95
#  undef G_HAVE_ISO_VARARGS
#endif

The only thing that fails is the definition of the PRINT() debugging
macro. That macro is only used in parse.l, so it can only fail in
parse.l. I'll try to appended a typescript of a build attempt that 
shows this if that damn BTS lets me.

Allright, so much to the accusations. For further questions,
typescripts and the like mail to <matt@mafr.de>. I *hate* this BTS,
you can't write text properly here.

Created attachment 15699 [details]
BSD-style typescript

Ok, I see the problem in parse.l.  Fixed.

Just tried to compile it, but it fails because select(2) is undefined.
You need to include unistd.h in gst/gstthreaddummy.c.

The other thing is the old problem with examples/manual/extract.pl.
/usr/bin/perl isn't the only place where the perl interpreter can
be installed. Use the /usr/bin/env trick. It works.
Or don't call ./extract.pl, but 'perl extract.pl' instead.

Everything else works fine now. Thanks for your help.

I've added unistd.h to gstthreaddummy.c. I'm leaving the other bug for
Thomas, I don't know how this is fixed normally. If nobody objects I
propose to just apply the other patch too...

Matthias, thanks!

I added an autoconf check for perl, so we should start using
$(PERL_PATH) in Makefile.am's to call perl scripts.  Eventually, when
someone finds a decent perl m4 file, we should be able to specify a
particular path to perl if the one found in $PATH is wrong.

I've been waiting for a few days, but the code leading to this warning 
(which isn't NetBSD related, of course) wasn't fixed in the meantime:

cc1: warnings being treated as errors
gstprops.c: In function `gst_props_entry_from_string_no_name':
gstprops.c:426: warning: value computed is not used

Thanks to everybody who helped so far.

Hi,

that last error:
- looks like an easyfix (I checked myself, but I can't be sure my line
numbers match yours and didn't see anything wrong at that line)
- doesn't seem to have anything to do with the original bug report

If the above is a genuine bug, please reopen a new bug so we can keep
track of bugs properly and know what we're fixing and what's been fixed.

Thanks