Closed dankelley closed 10 months ago
Here is the report. It looks easy to fix although I'll need to check that link to see if the stuff given after it is just a repeat. I'll try today because this is a super-busy time of year.
Whether I can find a test machine to check on whether my fix works is (as always) another question...
I will do the work in a new branch named cran-release-for-new-gcc
.
Since rhub tests often take hours (often with PREPERROR failures that have nothing to do with oce), I will try using docker image to test locally. Here are the steps to do this. (Note that I will edit this comment in-place as I go through them.)
rhub/debian-clang
(or is it rhub/debian-clang:latest
?) and then click the 'pull' button??? or maybe in terminal, do docker pull rhub/debian-clang
, which seems easier.... or maybe try as follows (from https://r-hub.github.io/rhub/articles/local-debugging.html)
local_check_linux(image="rhub/debian-clang-devel")
I've spent a few hours trying to get docker to reproduce the error, but man it's a slow process ... and the images that have 'clang' in the title do not actually use clang in the building process, so it was a total waste of time. Sheesh.
Luckily, there are now notes being produced on windows R-devel CRAN test machines, and I see that I can also test it with devtools::check_win_devel()
, so I'll be able to do this. No, the tests won't be local. But my time is not worth zero dollars and zero cents, and I will likely only need a few remote builds...
I have a lot of grading to do but I will take a break every once in a while to do more of this fiddly work. Since checklists on GH issues work poorly (often it forgets a few clicks) I'll make a checklist in the apple notes app, which is really quite convenient.
Expect to hear more from me later this week.
I've fixed this up, and now this and Clark's fix for #2173 both pass remote-windows-devel tests, as shown at https://win-builder.r-project.org/C5M4pyKY2Ixb/ (a link that will only live a few days, by design).
I am reopening this so I can record the following. I found that one of the github actions that gets run requires one C format, and that devtools::check_win_devel()
requires another. The screenshot shows the present state (which I will change in 5 minutes). The top is the output from devtools::check_win_devel()
, showing an error. But the bottom part is a git diff which (and you have to trust me on this) is the change I had to make for the R-CMD-check
action named ubuntu-latest-devel
to work.
So, we have a contradiction. I don't know how to know which is best.
I give up. Below is a commit note. The recommended scheme does not work. Maybe my (OSX) toolchain is not right. But I don't want to have oce in a state where I cannot build it. I'm just dropping this feature of stating values in some of the error messages. Users won't see the errors unless things are wrong, and they can easily just look at the arguments they gave to the function.
Since this has no problems on (a) my machine, (b) devtools::check_win_devel()
or (c) in the 4 machines tested with R-CMD-CHECK, I am proceeding to run check_package.R
from the source.
I have temporarily turned on the rhub
checks in that source, because you have to indicate that you have tested there during the submission process. The rhub results are often useless, e.g., taking 2 hours to get to a so-called PREPERROR that occurs before it even tries to build oce, but the submission process wants that, so I'll do it.
@richardsc and @clayton33 -- this is a long way of saying that my plan is to try to submit oce to CRAN very soon. I don't want to get close to the deadline in case what ought to be a quick process ends up burning days ... for those are days when I will be grading things, and I get paid to do that, not to work around C++ compilers on machines to which I have no access, and which are being tweaked by CRAN folks on what seems to be a daily basis.
The remote mac test shows as follows. I don't know whether to worry about this, but I note that the first two relate to source in oce, and the others (I think) do not.
I've never seen that warning on my intel box. Perhaps it's a feature of the M-series macs. @richardsc -- do you get that warning when you build on your M-series mac?
clang++ -arch arm64 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -o oce.so RcppExports.o ad2cp_ahrs.o adv_vector_time.o amsr.o approx.o bilinear_interp.o binmap.o bitwise.o coastline.o curl.o echosounder.o fillgap.o gappy_index.o geod.o get_bit.o gradient.o igrf12.o igrf13.o interp_barnes.o landsat.o ldc_ad2cp_in_file.o ldc_rdi_in_buffer.o ldc_rdi_in_file.o magdec.o map.o matrix_smooth.o oce_approx.o oce_convolve.o oce_filter.o ocecp.o registerDynamicSymbol.o run.o sfm_enu.o sontek_adp.o sw.o time.o trap.o trim.o -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/12.2.0 -L/opt/gfortran/lib -lgfortran -lemutls_w -lquadmath -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
ld: warning: could not create compact unwind for _igrf12syn_: registers 78 and 79 not saved contiguously in frame
ld: warning: could not create compact unwind for _igrf13syn_: registers 78 and 79 not saved contiguously in frame
ld: warning: could not create compact unwind for _md_driver_: registers 25 and 26 not saved contiguously in frame
ld: warning: could not create compact unwind for ___emutls_get_address: registers 23 and 24 not saved contiguously in frame
NB. the revdepcheck
tests were all OK, indicating that no package that depends on oce acquired errors (or warnings, I think) with the oce update.
NB. rhub results will be at the following links. (I will alter this comment in-place, as results become available. That won't likely be complete until this afternoon.)
windows-ucrt -- no C++ errors or warnings, but I see as below. I think the two things might be related. Since I do not see these messages elsewhere, I'm going to assume it's just a quirkiness of that rhub machine setup.
Ubuntu Linux 20.04.1 LTS, R-release, GCC -- no warnings or errors
Fedora Linux, R-devel, clang, gfortran There are warnings about int formats from various Rcpp source files, but not from oce itself.
Debian Linux, R-devel, GCC ASAN/UBSAN -- this format is quite different from the others, but I was able to check a few things (bilinear interpolation, etc) and there were no oce-specific warnings or errors.
Debian Linux, R-devel, clang, ISO-8859-15 locale -- no oce-related compiler warnings (but Rcpp ones, of course) in 67066 lines of output.
@dankelley in reply to your comment https://github.com/dankelley/oce/issues/2172#issuecomment-1831533387:
I see the following warnings when I build (R4.3.0 on MacOS12.7.1):
ld: warning: could not create compact unwind for _igrf12syn_: registers 76 and 77 not saved contiguously in frame
ld: warning: could not create compact unwind for _igrf13syn_: registers 76 and 77 not saved contiguously in frame
ld: warning: could not create compact unwind for _md_driver_: registers 25 and 26 not saved contiguously in frame
Hm, afraid of that. These are all for fortran code. I don't know any way to determine what the problem is. Therefore, my inclination is to ignore this and submit to CRAN. (Well, maybe I'll do some google searching on the message, but I do not want to alter the gravity code, which is the first two warnings.). Thanks for checking.
This is a call-out to co-developers @richardsc and @clayton33: I am planning on releasing oce to CRAN very soon, perhaps on the weekend. The issue is that I don't want to get anywhere near the deadline they have set, because if there is a last-minute problem, oce could get booted from CRAN and getting back on might be hard, given that we violate rules on size and time.
Also, I'm a bit buried in teaching and that will get worse in the next 2 weeks.
So, please let me know if you think there is anything that absolutely needs to be fixed in oce. If there is, I can try to dedicate some time to that next week (in between grading assignments...).
Thanks!!
Nothing from me !
commit f578e9d5b3837499809c487dc0c0b711209ce944 Author: dankelley kelley.dan@gmail.com Date: Fri Dec 1 06:23:55 2023 -0400
freeze code (run codemeta) in preparation for CRAN
I am now running the check_package.R
source file. This includes rhub checks that can take several hours to complete, but my guess is that by mid-afternoon, we will be clear for a CRAN submission today. Barring problems (and in light of other demands on my time), oce ought to be accepted before the deadline.
The checks are all fine for
The remote RHUB checks are as below. I'll check again later today. (Sometimes a check can take 2 to 4 hours.)
rhub::check_for_cran(email="Dan.Kelley@Dal.Ca", show_status=FALSE)
yields
rhub::check(platform="debian-clang-devel", show_status=FALSE)
yields
All those rhub checks are now done. (The slowest took almost 3 hours.). That means that I have done all the checks in the check_package.R
file.
My plan is to submit it to CRAN this afternoon. Every time I do that, there are new things tests that I have to pledge to have done, so that might cause a delay until tomorrow. (I add those checks to check_package.R
, which explains why it does so much.)
I just submitted it. Below is the confirmation email I got from CRAN. Now we wait.
Oooh, CRAN is fast today. The package is already starting to get a foot in the door.
Another hurdle has been passed (see the details below), but I'll keep this issue open until multiple versions become available on CRAN. Problems can be discovered after things seem okay on several machines. They will let me know if so, but I like to keep an issue open until some common platforms get pre-built binaries.
Below is a checklist, with things checked off as 1.8-2 becomes available on a CRAN mirror. I'll check once in a while for updates.
I'm not going to wait for the macOS r-oldrel , although I'll reopen this if I check again in a week and see that there are problems.
Dear maintainer,
Please see the problems shown on https://cran.r-project.org/web/checks/check_results_oce.html.
Please correct before 2023-12-11 to safely retain your package on CRAN.
Best,