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