[FFmpeg-devel] [PATCH] define _BSD_SOURCE for bktr.c
Sat Dec 13 23:03:08 CET 2008
On Sat, Dec 13, 2008 at 10:16:45PM +0100, Reimar D?ffinger wrote:
> On Sat, Dec 13, 2008 at 08:54:29PM +0000, Jacob Meuser wrote:
> > On Sat, Dec 13, 2008 at 02:26:57PM +0100, Reimar D?ffinger wrote:
> > > On Sat, Dec 13, 2008 at 01:07:15PM +0100, Reimar D?ffinger wrote:
> > > > > patch-tests_regression_sh: half-merged, half mysterious
> > > >
> > > > I just realized I made a bad assumption there, the sed expression
> > > > probably is wrong...
> > > > Which of course also means all this not a good solution, since we have
> > > > two different md5 binaries with no way to distinguish them except that
> > > > hopefully one is in the path and the other in /sbin, which is a bad
> > > > way...
> > > > I'll check if sed 's#.*= ##' is the right one (too many of the
> > > > regression tests fail, which is why I missed it originally).
> > >
> > > Oh silly me, it actually works right in the regression tests, I forgot
> > > to add -r when trying it on the command-line, so that part is okay.
> > > The LD_LIBRARY_PATH is just to allow make test without installing first,
> > > but it's not portable (e.g. won't work on Windows).
> > and did I submit this to you guys? no. why? because it's not
> > for upstream inclusion. so why bother saying it's not portable
> > to Windows?
> Well, because there is a lot of other stuff you did not submit but is
> necessary to make ffmpeg work on OpenBSD and acceptable.
> So we have to find out ourselves which parts are good and which are not,
> and I made clear that one isn't. In particular, it was not directed at
> you. And in particular 2) I felt the need to say it because I would have
> considered such a thing useful in the past too, but decided it to be a
> bad idea, in particular because of that.
> > it's like complaining that OpenBSD doesn't follow standards, then when
> > it does (_BSD_SOURCE vs POSIX), you complain that it's stupid.
> Uh, I only complained that its very own headers are not compatible amongst
> each other. Obviously sys/types.h should not define u_short etc. without
> _BSD_SOURCE but the bktr header should either fail in a cleaner way or
> not require u_short.
> > I dropped maintainership of ffmpeg because of all this needless
> > bashing. I hope you don't get an onslaught of idiots trying to
> > make ffmpeg work on OpenBSD ...
> I'm sorry if you do not like it, but the current OpenBSD patches
> IMHO certainly do not qualify as a "good" way of making it work,
> and if you truly think of most of them as more as quick-and-dirty hacks
> I don't think it can get that much worse.
> Still, bashing certainly was not even remotely the intention, getting
> things fixed was, a bit of bashing just makes all these workarounds a
> bit less annoying.
I have tried bringing up many of these issues in the past. I was
told to fix OpenBSD. I tried. I got gmake updated. I don't maintain
gcc, nm, or od or any of that other stuff. I mentioned some issues
but didn't get much response. I didn't really push it because it
seems silly to add the nm/od "standards compliance features" for just
one configure script (yes, ffmpeg is the only one).
maybe the way I was doing things wasn't quite the best, but there
was no review, just bashing.
and now I'm being told I never did anything. that's pretty insulting.
jakemsr at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
More information about the ffmpeg-devel