ACtually it doesn't seem obvious that it should be 32 if undefined :(

Does adding AC_SYS_LARGEFILE to configure.ac help?

Is that a zlib bug?
Or is that -Wundef being extra annoying again?

Also, that macro is not defined by any header, but you are supposed to define it yourself if you want 64bit functions (kinda like _LARGEFILE64_SOURCE).

I'd vote for defining this macro unconditionally in common/ for all GStreamer configure scripts - and I'd probably define it to 32, just to be sure we don't use weird code paths anywhere (and because - to quote Edward's link - "On 64 bit systems this macro has no effect").

(In reply to comment #2)
> Does adding AC_SYS_LARGEFILE to configure.ac help?

Yes, unless passing --disable-largefile to configure, because that causes _FILE_OFFSET_BITS to not be defined.

At least for the release (but also in general) I would very much prefer a local fix. Ultimately it's really just an annoying side effect of -Wundef really IMHO. But since this is all zlib API we're not using at all it doesn't really matter, we may just as well define it to 32 if it's undefined before including zlib.h.

I'm guessing the same is also needed for qtdemux and matroskademux?


> > Does adding AC_SYS_LARGEFILE to configure.ac help?
> 
> Yes, unless passing --disable-largefile to configure, because that causes
> _FILE_OFFSET_BITS to not be defined.

Well, sure, but as long as the default works, I'm perfectly happy to treat that similar to 'Doctor, my arm hurts when I hit it with a hammer', ie. 'don't do that then' ;-)

I tried using AC_SYS_LARGEFILE to configure.ac ... which ends up with the following in config.h on macosx 10.5:

/* Number of bits in a file offset, on hosts where this is settable. */
/* #undef _FILE_OFFSET_BITS */

Not very helpful I'd say :)

Python3 uses the following addition in configure.in and it fixes the issue on macosx 10.5:

# Enabling LFS on Solaris (2.6 to 9) with gcc 2.95 triggers a bug in
# the system headers: If _XOPEN_SOURCE and _LARGEFILE_SOURCE are
# defined, but the compiler does not support pragma redefine_extname,
# and _LARGEFILE64_SOURCE is not defined, the headers refer to 64-bit
# structures (such as rlimit64) without declaring them. As a
# work-around, disable LFS on such configurations

use_lfs=yes
AC_MSG_CHECKING(Solaris LFS bug)
AC_TRY_COMPILE([
#define _LARGEFILE_SOURCE 1
#define _FILE_OFFSET_BITS 64
#include <sys/resource.h>
],struct rlimit foo;,sol_lfs_bug=no,sol_lfs_bug=yes)
AC_MSG_RESULT($sol_lfs_bug)
if test "$sol_lfs_bug" = "yes"; then
  use_lfs=no
fi

if test "$use_lfs" = "yes"; then
# Two defines needed to enable largefile support on various platforms
# These may affect some typedefs
AC_DEFINE(_LARGEFILE_SOURCE, 1, 
[This must be defined on some systems to enable large file support.])
AC_DEFINE(_FILE_OFFSET_BITS, 64,
[This must be set to 64 on some systems to enable large file support.])
fi

Screw that. It'll fail a bit later on in -good when importing the libdv headers which use #if and not #ifdef.

I propose we remove -Wundef, it's just too tricky since it'll warn due to out-of-gstreamer issues.

+1

Yeah, I guess we should remove it. It's not our job to fix external headers to conform to our standards ;)

I'd like to keep it where possible, because it's quite useful when applied to our own headers and avoids screwups with macros (like the buffer metadata writable checks).

Off topic side note: Do you think it'd make sense to apply stricter CFLAGS to gst/ and gst-libs/ than to ext/ and sys/ ?

some code in gst/ imports external libraries (qtdemux importing zlib for ex).

Better remove it completely from any modules but core and base/gst-libs/

commit 5cd3896142ac2607ae486aca6ad6fd12c63e6dc4
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Mon Apr 12 12:40:11 2010 +0200

    configure: Remove -Wundef flag
    
    Fixes #615161