On recent CURRENT (FreeBSD 14.0-CURRENT #3 main-n262668-1f0e13449bee: Sun Apr 30 12:28:02 CEST 2023 amd64) with up to date ports tree, port math/R fails to configuer (and compile) due to the error shown below. tzsetup has been performed. I can't find any hint what to do to provide tzdata as the port's NEWS file stated: (work/R-4.3.0/doc/NEWS): ... * configure now checks conversion of datetimes between POSIXlt and POSIXct around year 2020. Failure (which has been seen on platforms missing tzdata) is fatal. ... [...] checking whether mktime, gmtime, localtime work correctly in 2020... no configure: error: date-time conversions do not work in 2020 -- is tzdata installed? ===> Script "configure" failed unexpectedly. Please report the problem to jrm@FreeBSD.org [maintainer] and attach the "/usr/ports/math/R/work/R-4.3.0/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 [...] Configuration of the port: # make showconfig ===> The following configuration options are available for R-4.3.0: ICU=on: Unicode support via ICU INFO=on: Build and/or install GNU info pages LDOUBLE=on: Long double data type LETTER=off: US letter paper MEMPROF=off: Memory profiling via Rprofmem() and tracemem() NLS=on: Native Language Support OPENMP=on: Parallel processing support via OpenMP RPROF=on: R profiling via Rprof() X11=on: X11 graphics device ====> Require X11 CAIROPANGO=on: Cairo graphics device and Pango multi-language text GHOSTSCRIPT=on: Graphics device for bitmap files via Ghostscript JPEG=on: JPEG graphics device PNG=on: PNG graphics device TCLTK=on: Tcl/Tk GUI toolkit support TEXDOCS=off: Build/Install TeX-dependent documentation files TIFF=on: TIFF image format support ====> Options available for the single BLAS: you have to select exactly one of them ATLAS=off: ATLAS blas implementation NETLIB=off: Netlib BLAS implementation OPENBLAS=off: OpenBLAS blas implementation RBLAS=on: Use R-bundled BLAS implementation ===> Use 'make config' to modify these settings
I didn't hit this when testing in a CURRENT poudriere jail, but that jail is not as up-to-day as your system. http://pkg.ftfl.ca/data/14amd64-default/2023-04-30_12h37m06s/logs/R-4.3.0.log Within the next day or two, I'll have a look at the test the configure script is running and see if we can nail down exactly what's failing.
I do not have this problem on a very recent CURRENT with also recent ports. Build on an unclean environment, outside of Poudriere.
(In reply to O. Hartmann from comment #0) Could you post the output of the config.log? Comparing it with a successful configure might give us some clues about what is failing.
(In reply to Rainer Hurling from comment #2) Thanks for confirming this.
I still suffer from that problem and do not have any clue what causes the misbehaviour. I've already have build R via "portmaster -df" to ensure every prerequisite port is up to date, but still I stumble into this error. Where to look? Maybe by understanding what test/check causes this error I'll possible find the flaw? Thanks.
build=built
Created attachment 242774 [details] Small test program extracted from R's configure script
It might still be useful to have your config.log. Could you also try running the attached test program, extracted from R's configure script? Here is what I see. jrm@phe ~/tmp/test_time % cc test_time.c -o test_time jrm@phe ~/tmp/test_time % ./test_time day 1577880000 2020-01-01 12:00:00 res 1593604800 2020-07-01 12:00:00 res 1577880000 2020-01-01 12:00:00 res 1593601200 2020-07-01 12:00:00 res 1577833200 2020-01-01 12:00:00 res 1593561600 2020-07-01 12:00:00
Friendly ping that I we're waiting on information. Will close in about two weeks otherwise.
(In reply to Joseph Mingrone from comment #9) Compiling the test_time.c program: ohartmann@thor [ohartmann]: cd /tmp/ ohartmann@thor [tmp]: cc test_time.c -o test_time ohartmann@thor [tmp]: ./test_time day 1577880027 2020-01-01 12:00:00 res 1593604827 2020-07-01 12:00:00 res 1577880027 2020-01-01 12:00:00 res 1593601227 2020-07-01 12:00:00 res 1577833227 2020-01-01 12:00:00 res 1593561627 2020-07-01 12:00:00
Created attachment 244258 [details] config.log of failing build (make) Non-poudriere, classical make driven build.
config.log see attached ...
(In reply to O. Hartmann from comment #10) The code from R's configure script is setting some struct tm to different dates like 2020-01-01 12:00 UTC, converting them to seconds since epoch, and verifying that the converted value is correct. For example, 2020-01-01 12:00:00 UTC is 1577880000 seconds since epoch. Your system reports that it's 1577880027, i.e. 27 more seconds than it should be, so it errors out. Something is up with your system. Maybe playing around with the date command will help. For example, if you also don't get 1577880000 when running % TZ=UTC date -j -f'%Y-%m-%dT%H:%M:%S' "2020-01-01T12:00:00" +%s you can start from there to try to figure out what's going on.