I'm noticing the following in lo builds on SunOS i386 (pkgsrc): [build CXX] pyuno/source/module/pyuno_module.cxx In file included from /tmp/pkgsrc/misc/libreoffice/work/.buildlink/include/python2.7/Python.h:8:0, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_impl.hxx:27, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno.cxx:46: /tmp/pkgsrc/misc/libreoffice/work/.buildlink/include/python2.7/pyconfig.h:1169:0: warning: "_FILE_OFFSET_BITS" redefined #define _FILE_OFFSET_BITS 64 ^ In file included from /usr/include/iso/stdlib_iso.h:49:0, from /usr/include/stdlib.h:37, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/include/sal/config.h:27, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno.cxx:20: /usr/include/sys/feature_tests.h:231:0: note: this is the location of the previous definition #define _FILE_OFFSET_BITS 32 ^ In file included from /tmp/pkgsrc/misc/libreoffice/work/.buildlink/include/python2.7/Python.h:8:0, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_impl.hxx:27, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_struct.cxx:33: /tmp/pkgsrc/misc/libreoffice/work/.buildlink/include/python2.7/pyconfig.h:1169:0: warning: "_FILE_OFFSET_BITS" redefined #define _FILE_OFFSET_BITS 64 ^ In file included from /usr/include/iso/stdlib_iso.h:49:0, from /usr/include/stdlib.h:37, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/include/sal/config.h:27, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_struct.cxx:20: /usr/include/sys/feature_tests.h:231:0: note: this is the location of the previous definition #define _FILE_OFFSET_BITS 32 ^ [build CXX] pyuno/source/module/pyuno_type.cxx [build CXX] pyuno/source/module/pyuno_util.cxx [build CXX] pyuno/source/module/pyuno_except.cxx [build CXX] pyuno/source/module/pyuno_adapter.cxx [build CXX] pyuno/source/module/pyuno_gc.cxx [build CXX] pyuno/source/module/pyuno_iterator.cxx In file included from /tmp/pkgsrc/misc/libreoffice/work/.buildlink/include/python2.7/Python.h:8:0, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_impl.hxx:27, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_iterator.cxx:24: /tmp/pkgsrc/misc/libreoffice/work/.buildlink/include/python2.7/pyconfig.h:1169:0: warning: "_FILE_OFFSET_BITS" redefined #define _FILE_OFFSET_BITS 64 ^ In file included from /usr/include/iso/stdlib_iso.h:49:0, from /usr/include/stdlib.h:37, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/include/sal/config.h:27, from /tmp/pkgsrc/misc/libreoffice/work/libreoffice-5.1.3.2/pyuno/source/module/pyuno_iterator.cxx:20: /usr/include/sys/feature_tests.h:231:0: note: this is the location of the previous definition #define _FILE_OFFSET_BITS 32 ^ The cause is that these pyuno modules include <sal/config.h> first which has: >#if defined LIBO_INTERNAL_ONLY >#include "config_global.h" >#endif > >#include <stdlib.h> config_global.h, even if LIBO_INTERNAL_ONLY, does not seem to deal with the primary configuration time necessary macros, namely: ... checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 ... So naturally stdlib.h already performs the feature_tests and fixes in concrete 32-bit runtime functions instead of the largefile functions. Redefining the macro later is useless because of the system header guards avoiding multiple inclusion issues. perhaps one or more of the config_host header files generated should include the configuration determined value of _FILE_OFFSET_BITS and be consequently included by config_global.h in order to not defeat the purpose of configuration in the first place.
I did notice LFS_CFLAGS in config_host.mk after configure (?, shouldn't it be CPPFLAGS and CXXCPPFLAGS) config_host.mk:export LFS_CFLAGS=-D_FILE_OFFSET_BITS=64 perhaps there is a quick workaround to use for the pyuno modules?
i wasn't aware of LFS_CFLAGS, it is used mostly in sal and a couple other libraries - why don't we just set it everywhere by adding it to gb_OSDEFS?
(In reply to Michael Stahl from comment #2) > i wasn't aware of LFS_CFLAGS, it is used mostly in sal and a couple other > libraries - why don't we just set it everywhere by adding it to gb_OSDEFS? sounds reasonable (probably ended up like this after a series of "just add it to this makefile to unbreak the build", followed by cargo-culting, followed by gbuild'ification)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62b75cd1698474b9232b46777e418de4786a3132 tdf#100302: gbuild: always use $(LFS_CFLAGS) It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
hope this is fixed on master