On 4/23/11 12:26 PM, Diego Biurrun wrote:
On Sat, Apr 23, 2011 at 01:04:49PM +0300, Martin Storsjö wrote:

As far as I can see, there's nothing else you can define to make it work,
except undefining _POSIX_C_SOURCE. Here's the relevant parts of
sys/cdefs.h
(http://gitweb.dragonflybsd.org/dragonfly.git/blob?f=sys/sys/cdefs.h):

#ifdef _POSIX_C_SOURCE
/* ...
  * Checking exact version of _POSIX_C_SOURCE, never setting __BSD_VISIBLE
  */
#else
/* ...
  * If a program mistakenly defines _ANSI_SOURCE and some other macro such
as
  * _POSIX_C_SOURCE, we will assume that it wants the broader compilation
  * environment (and in fact we will never get here).
  */
#ifdef _ANSI_SOURCE             /* Hide almost everything. */
#define __POSIX_VISIBLE         0
#define __XSI_VISIBLE           0
#define __BSD_VISIBLE           0
#define __ISO_C_VISIBLE         1990
#elif defined(_C99_SOURCE)      /* Localism to specify strict C99 env. */
#define __POSIX_VISIBLE         0
#define __XSI_VISIBLE           0
#define __BSD_VISIBLE           0
#define __ISO_C_VISIBLE         1999
#else                           /* Default environment: show everything.
*/
#define __POSIX_VISIBLE         200112
#define __XSI_VISIBLE           600
#define __BSD_VISIBLE           1
#define __ISO_C_VISIBLE         1999
#endif

#endif

This is the only place __BSD_VISIBLE is set under /usr/include as far as I
can see, and as long as _POSIX_C_SOURCE is defined, it will never be
defined. And __BSD_VISIBLE is required for inet_aton to be visible:
http://gitweb.dragonflybsd.org/dragonfly.git/blob?f=include/arpa/inet.h

It looks like another case of broken system headers to me...

Didn't perform the same check for FreeBSD yet, though...

The FreeBSD FATE box passes '-D__BSD_VISIBLE -D__XSI_VISIBLE=600' as
extra CFLAGS to configure:

http://fate.libav.org/x86_32-freebsd-gcc-4.4/20110423101824

I think the DragonFlay box should do the same.

I think we should report the problem there, possibly it will be fixed.

lu

_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to