/bin/sh ./libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./nauty -O2 -pipe -march=native -fno-diagnostics-color -c -o nauty.lo nauty.c /bin/sh ./libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./nauty -O2 -pipe -march=native -fno-diagnostics-color -c -o nautil.lo nautil.c /bin/sh ./libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./nauty -O2 -pipe -march=native -fno-diagnostics-color -c -o nausparse.lo nausparse.c In file included from ./nauty/naututil.h:127, from gtools.h:63, from dreadnaut.c:110: ./nauty/nauty.h:64:23: error: operator '==' has no left operand 64 | #if _FILE_OFFSET_BITS == 64 | ^~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_plasma_systemd-20231228-113459 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 17.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/17/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.6 Python 3.11.7 Available Rust versions: [1] rust-bin-1.74.1 [2] rust-1.74.1 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 17.0.8.1_p1 [openjdk-bin-17] 2) Eclipse Temurin JDK 21.0.1_p12 [openjdk-bin-21] *) Eclipse Temurin JDK 8.382_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 system-vm [2] openjdk-bin-17 [3] openjdk-bin-21 The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): go version go1.21.5 linux/amd64 HEAD of ::gentoo commit 8bc242178cf53d5aa28e6bda3d9e5f4b5acffeb8 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Dec 31 20:02:03 2023 +0000 2023-12-31 20:02:02 UTC emerge -qpvO sci-mathematics/nauty [ebuild N ] sci-mathematics/nauty-2.8.8 USE="-examples" CPU_FLAGS_X86="popcnt"
Created attachment 881146 [details] emerge-info.txt
Created attachment 881147 [details] emerge-history.txt
Created attachment 881148 [details] environment
Created attachment 881149 [details] etc.clang.tar.xz
Created attachment 881150 [details] etc.portage.tar.xz
Created attachment 881151 [details] logs.tar.xz
Created attachment 881152 [details] qlist-info.txt.xz
Created attachment 881153 [details] sci-mathematics:nauty-2.8.8:20231231-215658.log
Created attachment 881154 [details] temp.tar.xz
Like in the linked *magick bugs: """ dnl we need AC_SYS_LARGEFILE and AC_FUNC_FSEEKO AC_SYS_LARGEFILE AS_IF([test "x$ac_cv_sys_file_offset_bits" = xno],[ac_cv_sys_file_offset_bits=0]) AC_SUBST(ac_cv_sys_file_offset_bits) """ ac_cv_sys_file_offset_bits is an internal variable which got removed in refactoring. Not sure why they're even doing this, just use AC_SYS_LARGEFILE and such by itself...
*** Bug 921035 has been marked as a duplicate of this bug. ***
As far as I can see, the fix is trivial: with autoconf 2.72, AC_SYS_LARGEFILE is only having an effect (generating certain compiler options) on certain non-Linux systems. So it can safely be skipped, as I do by the following patch: diff --git a/configure.ac b/configure.ac index 55db18f..d87b345 100644 --- a/configure.ac +++ b/configure.ac @@ -164,8 +164,6 @@ CFLAGS=$user_cflags MORECFLAGS="" dnl we need AC_SYS_LARGEFILE and AC_FUNC_FSEEKO AC_SYS_LARGEFILE -AS_IF([test "x$ac_cv_sys_file_offset_bits" = xno],[ac_cv_sys_file_offset_bits=0]) -AC_SUBST(ac_cv_sys_file_offset_bits) AS_IF([test "x$user_cflags" = x || test "x$user_cflags" = x-m32], [ diff --git a/nauty-h.in b/nauty-h.in index f6c033d..f72cc11 100644 --- a/nauty-h.in +++ b/nauty-h.in @@ -60,13 +60,6 @@ it is necessary to check they are correct. #define FLEX_ARRAY_OK @flex_array_ok@ /* whether the compiler supports flexible array members in structures */ -#define _FILE_OFFSET_BITS @ac_cv_sys_file_offset_bits@ -#if _FILE_OFFSET_BITS == 64 -#define _LARGEFILE_SOURCE -#else -#undef _FILE_OFFSET_BITS -#endif - /* Support of gcc extensions __builtin_clz, __builtin_clzl, __builtin_clzll */ #ifndef HAVE_HWLZCNT #define HAVE_HWLZCNT @have_hwlzcnt@
(In reply to Dima Pasechnik from comment #12) > As far as I can see, the fix is trivial: with autoconf 2.72, > AC_SYS_LARGEFILE is only having an effect (generating certain compiler > options) on certain non-Linux systems. So it can safely be skipped, as I do > by the following patch: No, AC_SYS_LARGEFILE does stuff on Linux too. See my analysis in the IM bugs. > > diff --git a/configure.ac b/configure.ac > index 55db18f..d87b345 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -164,8 +164,6 @@ CFLAGS=$user_cflags > MORECFLAGS="" > dnl we need AC_SYS_LARGEFILE and AC_FUNC_FSEEKO > AC_SYS_LARGEFILE > -AS_IF([test "x$ac_cv_sys_file_offset_bits" = > xno],[ac_cv_sys_file_offset_bits=0]) > -AC_SUBST(ac_cv_sys_file_offset_bits) > > AS_IF([test "x$user_cflags" = x || test "x$user_cflags" = x-m32], > [ > diff --git a/nauty-h.in b/nauty-h.in > index f6c033d..f72cc11 100644 > --- a/nauty-h.in > +++ b/nauty-h.in > @@ -60,13 +60,6 @@ it is necessary to check they are correct. > #define FLEX_ARRAY_OK @flex_array_ok@ > /* whether the compiler supports flexible array members in structures */ > > -#define _FILE_OFFSET_BITS @ac_cv_sys_file_offset_bits@ You can't do this bit unless you're sure that it's already respecting what AC_SYS_LARGEFILE sets. Does the autoconf create a config.h or what?
I don't know what "the IM bugs" is, sorry. In /usr/share/gnulib/m4/largefile.m4 (where Gentoo's AC_SYS_LARGEFILE is coming from) one sees # _AC_SYS_LARGEFILE_OPTIONS # ------------------------- # List of known ways to enable support for large files. If you change # this list you probably also need to change the AS_CASE at the end of # _AC_SYS_LARGEFILE_PROBE. m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize( ["none needed"] dnl Most current systems ["-D_FILE_OFFSET_BITS=64"] dnl X/Open LFS spec ["-D_LARGE_FILES=1"] dnl 32-bit AIX 4.2.1+, 32-bit z/OS ["-n32"] dnl 32-bit IRIX 6, SGI cc (obsolete) )) Indeed, this leaves various #defines, according to the comment in the same file: # _AC_SYS_LARGEFILE_PROBE # ----------------------- # Subroutine of AC_SYS_LARGEFILE. Probe for large file support and set # the cache variable ac_cv_sys_largefile_opts to one of the values in # the _AC_SYS_LARGEFILE_OPTIONS list, or to "support not detected" if # none of the options in that list worked. Then, set compilation # options and #defines as necessary to enable large file support. later on, in _AC_SYS_LARGEFILE_PROBE one sees ac_have_largefile=yes AS_CASE([$ac_cv_sys_largefile_opts], ["none needed"], [], ["supported through gnulib"], [], ["support not detected"], [ac_have_largefile=no], ["-D_FILE_OFFSET_BITS=64"], [AC_DEFINE([_FILE_OFFSET_BITS], [64], [Number of bits in a file offset, on hosts where this is settable.])], ["-D_LARGE_FILES=1"], [AC_DEFINE([_LARGE_FILES], [1], [Define to 1 on platforms where this makes off_t a 64-bit type.])], ["-n32"], [CC="$CC -n32"], [AC_MSG_ERROR( [internal error: bad value for \$ac_cv_sys_largefile_opts])]) which indicates that the only possible Linux case is $ac_cv_sys_largefile_opts="-D_FILE_OFFSET_BITS=64" - which corresponds to "X/Open LFS spec" from above. What the latter is, I don't know. If we assume it can happen on Linux then indeed there is something left to do with _FILE_OFFSET_BITS.
here is a patch (only difference with the previous is in configure.ac) which passes the eventual AC_SYS_LARGEFILE-produced flags to the Makefile (via @MOREFLAGS@). It builds and works for me. I didn't check whether nauty*.pc are correctly built in case these flags are present. diff --git a/configure.ac b/configure.ac index 55db18f..49e6065 100644 --- a/configure.ac +++ b/configure.ac @@ -162,10 +162,14 @@ user_cflags="$CFLAGS" AC_PROG_CC CFLAGS=$user_cflags MORECFLAGS="" -dnl we need AC_SYS_LARGEFILE and AC_FUNC_FSEEKO AC_SYS_LARGEFILE -AS_IF([test "x$ac_cv_sys_file_offset_bits" = xno],[ac_cv_sys_file_offset_bits=0]) -AC_SUBST(ac_cv_sys_file_offset_bits) +AS_CASE([$ac_cv_sys_largefile_opts], + ["none needed"], [], + ["support not detected"], [], + dnl otherwise it is a compiler flag + [MORECFLAGS="$MORECFLAGS $ac_cv_sys_largefile_opts"] + ) + AS_IF([test "x$user_cflags" = x || test "x$user_cflags" = x-m32], [ diff --git a/nauty-h.in b/nauty-h.in index f6c033d..f72cc11 100644 --- a/nauty-h.in +++ b/nauty-h.in @@ -60,13 +60,6 @@ it is necessary to check they are correct. #define FLEX_ARRAY_OK @flex_array_ok@ /* whether the compiler supports flexible array members in structures */ -#define _FILE_OFFSET_BITS @ac_cv_sys_file_offset_bits@ -#if _FILE_OFFSET_BITS == 64 -#define _LARGEFILE_SOURCE -#else -#undef _FILE_OFFSET_BITS -#endif - /* Support of gcc extensions __builtin_clz, __builtin_clzl, __builtin_clzll */ #ifndef HAVE_HWLZCNT #define HAVE_HWLZCNT @have_hwlzcnt@
nauty*.pc still need a fix. They are made by substituting some templates there by ./configure, and the rest of templates by make. I will add a special template in nauty-pc.in to fix this.
Created attachment 885625 [details, diff] patch to correct the use of AC_SYS_LARGEFILE with autoconf 2.72 this fixes the problem by adding the flags (if any) output by AC_SYS_LARGEFILE to CFLAGS to be used in Makefile, as well as in nauty.pc
(In reply to Dima Pasechnik from comment #17) > Created attachment 885625 [details, diff] [details, diff] > patch to correct the use of AC_SYS_LARGEFILE with autoconf 2.72 > > this fixes the problem by adding the flags (if any) output by > AC_SYS_LARGEFILE to CFLAGS to be used in Makefile, as well as in nauty.pc That looks right, in lieu of them using autoconf's proper config.h setup.
> using autoconf's proper config.h setup. no need for config.h here. config.h is only needed when there is a need to pass a lot of #define's to the package build (it goes without saying that one does not install `config.h`, it's only used for building the project). My patch passes the needed flag (in effect, a #define passed via -D compiler option) to the build directly, via an existing template in makefile.in. And it installs this flag into nauty.pc, too, so that a user linking libnauty in an application can extract the correct compiler flag to build their application.
Yes, I'm just saying it would've been tidier if they'd used it properly rather than the hack they did originally for _F_O_B. It was just an aside.
I was going to look at this over the weekend but I got COVID again and my brain is mush. I think the patch looks OK considering the explanation in Comment 14. Sam, did you have any other concerns? Upstream may take a while to get to this.
It looks good to me now, thanks!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=177ed9f2185d6f1f7b64a475169a9ed0b18989b8 commit 177ed9f2185d6f1f7b64a475169a9ed0b18989b8 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2024-03-12 01:56:27 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-03-12 01:59:17 +0000 sci-mathematics/nauty: fix build with autoconf-2.72 New patch fixes AC_SYS_LARGEFILE issues. Thanks to Dima Pasechnik for doing the legwork. Closes: https://bugs.gentoo.org/921138 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../nauty/files/nauty-2.8.8-autoconf-2.72.patch | 53 ++++++++++++++ sci-mathematics/nauty/nauty-2.8.8-r1.ebuild | 80 ++++++++++++++++++++++ 2 files changed, 133 insertions(+)
