pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/57074: sysutils/pv fails to build on modern MacOS, tries to use stat64
The following reply was made to PR pkg/57074; it has been noted by GNATS.
From: dns%strangeloop.cc@localhost
To: gnats-bugs%netbsd.org@localhost
Cc: pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/57074: sysutils/pv fails to build on modern MacOS, tries to
use stat64
Date: Fri, 28 Oct 2022 00:27:21 +0300
On 2022-10-27 01:15, David Holland wrote:
> The following reply was made to PR pkg/57074; it has been noted by
> GNATS.
>
> From: David Holland <dholland-pbugs%netbsd.org@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc:
> Subject: Re: pkg/57074: sysutils/pv fails to build on modern MacOS,
> tries to
> use stat64
> Date: Wed, 26 Oct 2022 22:13:16 +0000
>
> On Tue, Oct 25, 2022 at 04:25:00PM +0000, dns%strangeloop.cc@localhost wrote:
> > .if ${OPSYS} == "Darwin" && ${MACHINE_ARCH} == "aarch64"
> > CONFIGURE_ENV+= ac_cv_func_stat64=no
> > .endif
> >
> > Will this break build on other Darwin's or older Mac's? Maybe
> > checking OPSYS_VERSION > 120000 is a better deal? Unfortunately I
> > don't know much about Mac's and my system is currently 120600.
>
> It might. The whole sorry history of this stat64 nonsense has a lot of
> tentacles. But probably not since aarch64 MacOS doesn't go back very
> far.
>
> I guess the other question is: why does the configure test come up
> with the wrong answer? If we can figure out what's up with that, it's
> a more robust way to fix things. config.log may provide some insight.
>
> --
> David A. Holland
> dholland%netbsd.org@localhost
I tried my best and I did eventually came up with this diff, which
should explain things. I included a few more lines to show how the
macros work:
--- autoconf/header.in.orig 2021-09-04 22:59:47.000000000 +0300
+++ autoconf/header.in 2022-10-28 00:02:23.000000000 +0300
@@ -58,21 +58,21 @@
#ifdef ENABLE_LARGEFILE
# define __USE_LARGEFILE64 1
# define _LARGEFILE64_SOURCE 1
#else
/*
* Some Macs have stat64 despite not having open64 while others don't
have
* either, so here even if we don't have open64 or LFS is disabled, we
have
* to check whether stat64 exists and only redefine it if it doesn't
* otherwise some Macs fail to compile.
*/
-# ifdef __APPLE__
+# if defined(__APPLE__) && !defined(_DARWIN_FEATURE_64_BIT_INODE)
# ifndef HAVE_STAT64
# define stat64 stat
# define fstat64 fstat
# define lstat64 lstat
# endif
# else
# define stat64 stat
# define fstat64 fstat
# define lstat64 lstat
# endif
I could not easily get around the detection of HAVE_STAT64 (autoconf
defines this from successful compilation of function stat64(2)) but by
using this "64_BIT_NODE" macro, defined on modern (Mac OSX 10.5 or
higher) systems, this will ignore HAVE_STAT64 and fallback to the
default behaviour of other OS's, which is to "define stat64 stat" and
hence fix the code.
So, until Apple removes stat64(2) altogether this should work.. :)
Cheers,
Dennis
Home |
Main Index |
Thread Index |
Old Index