coreutils @8.29, gzip @1.9 +universal: This package requires a 64-bit 'time_t' type

[dershow]

coreutils upgraded from 8.28_2 to 8.29_0, but when I try to do the upgrade, it fails to configure. Log is attached.

[ryandesign (Ryan Carsten Schmidt)]

The relevant error seems to be:

configure: error: This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.

I see you are intentionally building a universal variant, with both 32-bit and 64-bit parts. I guess if we want to continue to allow universal builds, we should add TIME_T_32_BIT_OK=yes for the 32-bit parts, as it says.

Curiously, there was no problem building coreutils on our 32-bit i386 Snow Leopard and ppc Leopard builders. I guess the configure script recognizes that on those systems, 64-bit types are not supported, so it allows the build to proceed?

[dershow]

I don't believe that I actually directly installed coreutils, but instead it was installed as a dependent of something else, and that must have required +universal.

[dershow]

I just changed both from +universal and now they install fine.

[thetrial (alabay)]

Could you please explain?

I ran into this, too, and reverted via Time Machine. My main problem was, that my (macports) zsh did not start anymore due to »dyld: Library not loaded: /usr/local/lib/libgdbm.4.dylib« … seems that this started with this aborted install.

I use two machines, a 2009 MBP, there everything was updated finde, and a MP 1,1 – there the update stopped, no working zsh, hassle.

So, what to do?

[ryandesign (Ryan Carsten Schmidt)]

Replying to thetrial:

My main problem was, that my (macports) zsh did not start anymore due to »dyld: Library not loaded: /usr/local/lib/libgdbm.4.dylib« … seems that this started with this aborted install.

This does not sound in any way related to this ticket. See wiki:FAQ#usrlocal.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

The relevant error seems to be:

configure: error: This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.

It looks like this was added to coreutils ​to raise awareness of the year 2038 problem.

I guess if we want to continue to allow universal builds, we should add TIME_T_32_BIT_OK=yes for the 32-bit parts, as it says.

I think it's probably ok to do this. If we wanted to add TIME_T_32_BIT_OK only to the 32-bit parts, we would have to use the muniversal portgroup. Or we could try always supplying TIME_T_32_BIT_OK and see if the 64-bit parts will successfully ignore it. Or we could rip the TIME_T_32_BIT_OK code out of the configure script.

[thetrial (alabay)]

Replying to ryandesign:

Replying to thetrial:

My main problem was, that my (macports) zsh did not start anymore due to »dyld: Library not loaded: /usr/local/lib/libgdbm.4.dylib« … seems that this started with this aborted install.

This does not sound in any way related to this ticket. See wiki:FAQ#usrlocal.

Well, I see, but there are several things: This problem started exactly with this interruption. And it claims something that is missing there, not that is additional in there. I look into my other machine, there is no libgdbm.4.dylib there either. So the macports zsh broke. That was built in the same go where the coreutils stopped, I thought, this might be the problem.

The things in /usr/local/ are on both machines the same, and they are MacGPG2, cutedge-postfix stuff, texlive and an own tin. So this can’t be the reason. I am a bit confused. Maybe these are two (or three?) different problems and one big coincidence, but my coreutils stopped from building, zsh stopped working and this hint with /usr/local/lib/ came up. That never happened before. In addition lots of clang-stuff is added (versions and versions), so I’m not sure where to start and what to do.

However, I had the same message with coreutils, so I might be affected. Though I’m surpised my last update of macports worked an the MacBook Pro and failed on the Mac Pro.

BTW, is there a way to use the trace -t mode when updating outdated in one go? If one does not know what exactly has problems? Or is there a options switch?

[thetrial (alabay)]

I now checked which ports were outdated and did not updated but »installed« them with the -t option. Now everything works well, even coreutils went through. What really makes me wonder … although clang 4 and 5 were updated, this took only minutes. Normally an update takes hours or a whole night. Is it possible to use -t with an update/upgrade command? Or to make that default?

[dClauzel (Damien Clauzel)]

Same problem here. I can upgrade coreutils, but only by omitting the +universal variant.

# CPPFLAGS="-m64" LDFLAGS="-m64" port install coreutils
--->  Computing dependencies for coreutils
--->  Fetching archive for coreutils
--->  Attempting to fetch coreutils-8.29_0.darwin_17.x86_64.tbz2 from https://packages.macports.org/coreutils
--->  Attempting to fetch coreutils-8.29_0.darwin_17.x86_64.tbz2.rmd160 from https://packages.macports.org/coreutils
--->  Installing coreutils @8.29_0
--->  Deactivating coreutils @8.28_2+universal
--->  Cleaning coreutils
--->  Activating coreutils @8.29_0
--->  Cleaning coreutils
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files 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/

# CPPFLAGS="-m64" LDFLAGS="-m64" port install coreutils +universal
--->  Computing dependencies for coreutils
--->  Fetching archive for coreutils
--->  Attempting to fetch coreutils-8.29_0+universal.darwin_17.i386-x86_64.tbz2 from https://packages.macports.org/coreutils
--->  Attempting to fetch coreutils-8.29_0+universal.darwin_17.i386-x86_64.tbz2 from http://lil.fr.packages.macports.org/coreutils
--->  Attempting to fetch coreutils-8.29_0+universal.darwin_17.i386-x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/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_release_tarballs_ports_sysutils_coreutils/coreutils/work/coreutils-8.29/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_release_tarballs_ports_sysutils_coreutils/coreutils/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port coreutils failed

# port installed coreutils
The following ports are currently installed:
  coreutils @8.28_2+universal
  coreutils @8.29_0 (active)

[ryandesign (Ryan Carsten Schmidt)]

Replying to thetrial:

Having libraries installed in /usr/local will cause problem for MacPorts, as it has for your zsh. Remove what you have installed in /usr/local and rebuild the affected ports (i.e. zsh).

Trace mode can help avoid interference from /usr/local. Recent discussion about enabling trace mode by default is ​here.

If an update that usually takes hours took just minutes, that means you received a pre-compiled binary from our build server instead of building it yourself.

None of that has anything to do with this ticket, which is about the fact that the developers of coreutils have added year-2038 awareness code in version 8.29 (and the developers of gzip have now done so as well in version 1.9) which causes the ports to fail to build when the universal variant is used. This ticket is about that problem only, and discussions of other problems should happen elsewhere.

If you have other questions about how MacPorts works, please write to the macports-users mailing list.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dClauzel:

Same problem here. I can upgrade coreutils, but only by omitting the +universal variant.

Yes, we know. All users who try to install coreutils or gzip with the universal variant will experience this problem. That's why this ticket is still open.

# CPPFLAGS="-m64" LDFLAGS="-m64" port install coreutils

MacPorts deliberately ignores most environment variables specified at the command line, so you cannot influence the CPPFLAGS, LDFLAGS, etc. that the port uses in this way, nor is it usually a good idea to attempt to do so, since ports deliberately use the flags they use. The -m64 compiler flag means "build 64-bit", which is the default on 64-bit Macs running Mac OS X 10.6 and later. The +universal MacPorts variant means "build 64-bit and 32-bit" on 64-bit Macs, so it's nonsense to try to tell such a build to use -m64.

[ryandesign (Ryan Carsten Schmidt)]

In 76b5fb575d6c90432dde388a8e1562e8ef72287b/macports-ports:

coreutils: Fix universal variant

Closes: #55643

[ryandesign (Ryan Carsten Schmidt)]

In cd2607c21c4d49dae627b672aa479e195a03d8ce/macports-ports:

gzip: Fix universal variant

Closes: #55643

[Ionic (Mihai Moldovan)]

This ticket is a bit old now and the issue has already been fixed, but isn't the fix a bit too broad?

The configure check is fine for arches like x86_64 or ppc64, but we generally disable it now. I believe we should only add the option for 32-bit arches.

[Ionic (Mihai Moldovan)]

How about backporting the fix from #59184 instead? (The commit message is wrong, momentary lapse.)

[ryandesign (Ryan Carsten Schmidt)]

Feel free to do so if it's important to you. Note that the fix from #59184 relies on the fact that findutils is using the muniversal portgroup, and so far coreutils isn't. If you change coreutils to use that portgroup, make sure that doesn't introduce other problems. Another way to do it would be to apply the flag only if a 32-bit architecture appears in [get_canonical_archs].

[Christopher Nielsen <mascguy@…>]

In ee2681da0d281112bf6cafc1b4c917de90da6a2f/macports-ports (master):

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