coreutils - configure: error: The 'time_t' type stops working after January 2038, and your system appears to support a wider 'time_t'

[RobK88]

I am unable to configure and install the coreutils +universal variant on High Sierra.

configure: error: The 'time_t' type stops working after January 2038,
                   and your system appears to support a wider 'time_t'.
                   Try configuring with 'CC="/usr/bin/clang -m64"'.
                   To build with a 32-bit time_t anyway (not recommended),
                   configure with '--disable-year2038'.

[mascguy (Christopher Nielsen)]

This was fixed four weeks ago, via issue:65457.

Is your ports tree up-to-date? If so, have you made any local modifications to the portfile for coreutils?

[RobK88]

No. I just installed XCode 10.1 and Macports on my old Macbook Pro running High Sierra. A new installation of MacPorts is supposed to do an initial sync. But I ran sudo port -v selfupdate just in case.

Than I proceeded to install some ports. Coreutils ss one of tee first ports that I try to install.

[RobK88]

The problem appears to be ONLY with the +universal variant.

Coreutils appears to configure and build just fine without specifying the +universal variant. (ie. the x64 bit binary). See below:

Grinchs-MacBook-Pro:~ grinch$ sudo port sync
--->  Updating the ports tree
Grinchs-MacBook-Pro:~ grinch$ 
Grinchs-MacBook-Pro:~ grinch$ sudo port clean coreutils
--->  Cleaning coreutils
Grinchs-MacBook-Pro:~ grinch$ 
Grinchs-MacBook-Pro:~ grinch$ sudo port install coreutils +universal
--->  Computing dependencies for coreutils
--->  Fetching archive for coreutils
--->  Attempting to fetch coreutils-9.1_0+universal.darwin_17.i386-x86_64.tbz2 from http://ywg.ca.packages.macports.org/mirror/macports/packages/coreutils
--->  Attempting to fetch coreutils-9.1_0+universal.darwin_17.i386-x86_64.tbz2 from http://mse.uk.packages.macports.org/coreutils
--->  Attempting to fetch coreutils-9.1_0+universal.darwin_17.i386-x86_64.tbz2 from http://fra.de.packages.macports.org/coreutils
--->  Fetching distfiles for coreutils
--->  Verifying checksums for coreutils
--->  Extracting coreutils
--->  Configuring coreutils
Error: Failed to configure coreutils: consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_coreutils/coreutils/work/coreutils-9.1/config.log
Error: Failed to configure coreutils: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_coreutils/coreutils/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port coreutils failed
Grinchs-MacBook-Pro:~ grinch$
Grinchs-MacBook-Pro:~ grinch$ sudo port clean coreutils
--->  Cleaning coreutils
Grinchs-MacBook-Pro:~ grinch$ sudo port -s install coreutils
--->  Computing dependencies for coreutils
--->  Fetching distfiles for coreutils
--->  Verifying checksums for coreutils
--->  Extracting coreutils
--->  Configuring coreutils
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
  re_search: found in coreutils-9.1/config.log
  re_compile_pattern: found in coreutils-9.1/config.log
  re_set_syntax: found in coreutils-9.1/config.log
  MIN: found in coreutils-9.1/config.log
  __fpending: found in coreutils-9.1/config.log
  free: found in coreutils-9.1/config.log
  strchr: found in coreutils-9.1/config.log
  re_match: found in coreutils-9.1/config.log
--->  Building coreutils
--->  Staging coreutils into destroot                    
--->  Installing coreutils @9.1_0                        
--->  Activating coreutils @9.1_0
--->  Cleaning coreutils
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  coreutils has the following notes:
    The tools provided by GNU coreutils are prefixed with the character 'g' by default to distinguish them from the BSD
    commands.
    For example, cp becomes gcp and ls becomes gls.
    
    If you want to use the GNU tools by default, add this directory to the front of your PATH environment variable:
        /opt/local/libexec/gnubin/
Grinchs-MacBook-Pro:~ grinch$

[mascguy (Christopher Nielsen)]

Replying to RobK88:

The problem appears to be ONLY with the +universal variant.

Understood, and the prior fix addressed that. (At least for older macOS releases.)

I'll have to test building universal on 10.13. Stay tuned.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mascguy:

This was fixed four weeks ago, via issue:65457.

Not really. The commits there only apply the fix when the build_arch is i386, which is not the case when building universal on an x86_64 system. Why was the condition on build_arch thought to be necessary? The previous fix I committed five years ago was unconditional and as far as I know has been fine, they've just now apparently changed the mechanism by which it needs to be specified (configure arg now instead of variable).

It was suggested in comment:ticket:55643:14 that the fix in coreutils should be conditional, and the findutils port does make it conditional, but it is able to do so because it uses the muniversal portgroup, which coreutils does not (and introducing the muniversal portgroup can cause other problems hence it should not be used indiscriminately).

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

Not really. The commits there only apply the fix when the build_arch is i386, which is not the case when building universal on an x86_64 system. Why was the condition on build_arch thought to be necessary? The previous fix I committed five years ago was unconditional and as far as I know has been fine, they've just now apparently changed the mechanism by which it needs to be specified (configure arg now instead of variable).

It was suggested in comment:ticket:55643:14 that the fix in coreutils should be conditional, and the findutils port does make it conditional, but it is able to do so because it uses the muniversal portgroup, which coreutils does not (and introducing the muniversal portgroup can cause other problems hence it should not be used indiscriminately).

Still wrapping my head around Universal-related details, but slowly getting there.

And thanks for the heads-up, I'll take a look.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

Not really. The commits there only apply the fix when the build_arch is i386, which is not the case when building universal on an x86_64 system. Why was the condition on build_arch thought to be necessary? The previous fix I committed five years ago was unconditional and as far as I know has been fine, they've just now apparently changed the mechanism by which it needs to be specified (configure arg now instead of variable).

The goal was to avoid unconditionally disabling support for 64-bit times, hence the check. And despite still being mentioned in upstream's Readme, TIME_T_32_BIT_OK doesn't appear to be supported any longer.

So we need a conditional check.

[ryandesign (Ryan Carsten Schmidt)]

I don't think we need a conditional check. As far as I understand it, --disable-year2038 (previously TIME_T_32_BIT_OK=yes) merely tells the configure script not to error out if time_t is 32-bit. It has no effect if time_t is 64-bit.

My understanding is that time_t is 64-bit on 64-bit macOS and 32-bit on 32-bit macOS. If we want to support building for 32-bit macOS, either standalone or universal, then we need to disable the error.

It's a little confusing but you can look at the code behind the --disable-year2038 switch here: ​https://github.com/coreutils/gnulib/blob/master/m4/year2038.m4

[Christopher Nielsen <mascguy@…>]

In ee2681da0d281112bf6cafc1b4c917de90da6a2f/macports-ports (master):

coreutils/coreutils-devel: fix year 2038 check
See: #55643
See: #65457
Fixes: #65673