[MPlayer-cvslog] r36022 - trunk/configure

[Diego Biurrun]

On Sun, Mar 24, 2013 at 12:46:27AM +0100, Reimar Döffinger wrote:
> On 23 Mar 2013, at 15:44, Diego Biurrun <diego at biurrun.de> wrote:
> > On Sat, Mar 23, 2013 at 01:55:42PM +0100, Reimar Döffinger wrote:
> >> On Fri, Mar 22, 2013 at 06:55:03PM +0100, Diego Biurrun wrote:
> >>> You misread.  The wrong approach is trying to find a set of flags that
> >>> all libcs can handle.  The right approach is setting individual flags
> >>> for each libc.  I did this for glibc.
> >> 
> >> Maybe it will be necessary to add a special case for each libc.
> >> But that still leaves the question what should be the "default"
> >> case for C libraries we haven't added a special case for.
> >> And you opted for the default behaviour to be not setting these flags.
> > 
> > New libcs don't appear on the scene every other week.  If one should
> > appear, we will possibly have to add fresh flags for it.  Or maybe it
> > will just work without any flags, like FreeBSD.
> > 
> > That does not change the fact that trying to find common flags is a
> > fool's errand.  Been there, done that, it's not humanly feasible.
> 
> Which, I repeat, was not my point. Not even remotely.
> The POSIX documentation says:
> > A POSIX-conforming application should ensure that the feature test
> > macro _POSIX_C_SOURCE is defined before inclusion of any header.
>
> Why should it be reasonable that we by default do _not_ do what POSIX says?
> I BSD doesn't work with that, sure detect it and do something else.

Sure, one could switch the condition to 'if !freebsd ..' and keep adding
other systems (likely at least the other *bsds); but I remain unconvinced
that this is particularly robust.

Trouble is that different libcs react differently to that define.  There
is no consistent behavior: on some systems that flag turns features on,
on others it turns features off.  So unconditionally enabling it will
always break either one system or another.

> But I take issue with making going against POSIX by default.
> Even more so since there already now exist a lot more libcs than BSD
> and glibc,

I know.  Still the only newcomers in the field in the last 10 years appear
to be bionic, eglibc and musl, not very much ...

> out of my head at least uclibc, bionic (or whatever Android
> uses), msvcrt

uclibc masquerades as glibc and is thus covered; msvcrt is not even remotely
supported; bionic I don't know.

Diego