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.
i too have this problem. on 13.3-RELEASE-p4: root@yoda:~ # env TZ=UTC date -j -f'%Y-%m-%dT%H:%M:%S' "2020-01-01T12:00:00" +%s 1577880027 my src.conf: WITH_EXTRA_TCP_STACKS=1 WITH_BHYVE_SNAPSHOT=1 WITH_ZONEINFO_LEAPSECONDS_SUPPORT=1 will check if a new world lacking ZONEINFO_LEAPSECONDS_SUPPORT changes things and report back
(In reply to Chad Jacob Milios from comment #14) > will check if a new world lacking ZONEINFO_LEAPSECONDS_SUPPORT changes things and report back Hello Chad. Did you come to any conclusions?
(In reply to Joseph Mingrone from comment #15) hey, i'm sorry; i totally spaced on this one. i never built my world without the leapseconds support and right now i'm minutes away from setting sail where i'll be incommunicado for a couple weeks. i do recall that in my runs i extracted that test as well and it put my wallclock at 27 seconds later than the test expected. the arbitrary odd number is what led me to wonder if it was because i opted in to leapsecond support in src.conf. i simply patched the test script in my local tree to rather than use an `==` test to instead pass on a window of 120 seconds +/- 60s; an ugly punt, i know. i imagine it's looking for at least 15 minutes off to really be considered a failure. (yes, there are definitely 1/2 hr and maybe even 1/4 hr offset regional timezones, out there somewheres, methinks) my local R port build hasnt sent my rocketship careening off course into the sun, yet. i'm not the foremost expert on the implications here, though.
Created attachment 259387 [details] patch for FILESDIR; a workaround for testing (NOT a sound solution) (In reply to Joseph Mingrone from comment #15) WITH_ZONEINFO_LEAPSECONDS_SUPPORT (see man src.conf) definitely caused it. WITHOUT_ZONEINFO_LEAPSECONDS_SUPPORT (default) definitely alleviates it. attached is a workaround which will allow R to build with it on (until the next leap second...so far there've been 27) after build, R "seems" to "work". however, i do not truly flex R so i cannot speak to it's correctness or effectiveness under this condition.
Related DR: https://reviews.freebsd.org/D25902
Thanks for your insight on this Chad. I just pushed 5d50c2397a from https://reviews.freebsd.org/D25902. Sorry, I should have added you to the 'Reviewed by:' field on the commit log. Any objections to closing this?
(In reply to Joseph Mingrone from comment #19) None at all. LGTM. Thanks for following through on this unexciting PR and pushing that seemingly trivial DR to landing.