#69849 closed defect (fixed)
R-minqa @1.2.6: clang: error: no such file or directory: 'WARNING:'
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | barracuda156 |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.9.3 |
| Keywords: | Cc: | ||
| Port: | R-minqa |
Description
This might be specific to this older builder but the failure mode is still strange:
clang: error: no such file or directory: 'WARNING:' clang: error: no such file or directory: 'too' clang: error: no such file or directory: 'small' clang: error: no such file or directory: 'maximum' clang: error: no such file or directory: 'for' clang: error: no such file or directory: 'v(ector' clang: error: no such file or directory: 'heap)size' clang: error: no such file or directory: ''0'' clang: error: no such file or directory: 'ignored,' clang: error: no such file or directory: 'the' clang: error: no such file or directory: 'current' clang: error: no such file or directory: 'usage' clang: error: no such file or directory: '64M' clang: error: no such file or directory: 'is' clang: error: no such file or directory: 'already' clang: error: no such file or directory: 'larger' clang: error: no such file or directory: 'WARNING:' clang: error: no such file or directory: 'too' clang: error: no such file or directory: 'small' clang: error: no such file or directory: 'maximum' clang: error: no such file or directory: 'for' clang: error: no such file or directory: 'v(ector' clang: error: no such file or directory: 'heap)size' clang: error: no such file or directory: ''0'' clang: error: no such file or directory: 'ignored,' clang: error: no such file or directory: 'the' clang: error: no such file or directory: 'current' clang: error: no such file or directory: 'usage' clang: error: no such file or directory: '64M' clang: error: no such file or directory: 'is' clang: error: no such file or directory: 'already' clang: error: no such file or directory: 'larger' make: *** [minqa.so] Error 1 ERROR: compilation failed for package ‘minqa’
Change History (17)
comment:1 Changed 7 months ago by barracuda156
comment:2 follow-ups: 3 6 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
comment:3 Changed 7 months ago by barracuda156
Replying to ryandesign:
And it's not the only case.
So it only happens on i386? Cannot say anything at the moment, but I will try reproducing it.
comment:4 Changed 7 months ago by barracuda156
Oh wow, it is actually broken now:
---> Extracting minqa_1.2.6.tar.gz
Executing: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-minqa/R-minqa/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/R-minqa/minqa_1.2.6.tar.gz' | /usr/bin/gnutar --no-same-owner -xf -
---> Configuring R-minqa
Executing: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-minqa/R-minqa/work/minqa" && /opt/local/bin/R CMD build . --no-manual --no-build-vignettes --keep-empty-dirs
WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger
WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger
* checking for file ‘./DESCRIPTION’ ... OK
* preparing ‘minqa’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* building ‘minqa_1.2.6.tar.gz’
---> Building R-minqa
xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-minqa/R-minqa/work/build
Executing: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-minqa/R-minqa/work/minqa" && /opt/local/bin/R CMD INSTALL . --library=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_R_R-minqa/R-minqa/work/build --install-tests
WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger
WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger
* installing *source* package ‘minqa’ ...
** package ‘minqa’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
using Fortran compiler: ‘GNU Fortran (MacPorts gcc13 13.2.0_4+stdlib_flag) 13.2.0’
using C++ compiler: ‘g++-mp-13 (MacPorts gcc13 13.2.0_4+stdlib_flag) 13.2.0’
Warning in system2("xcrun", "--show-sdk-path", TRUE, TRUE) :
running command ''xcrun' --show-sdk-path 2>&1' had status 64
using SDK: ‘NA’‘NA’‘NA’‘NA’‘NA’‘NA’
/opt/local/bin/gfortran-mp-13 -fPIC -pipe -Os -m32 -c altmov.f -o altmov.o
altmov.f:42:72:
. . .
Warning: Fortran 2018 deleted feature: Shared DO termination label 60 at (1)
/opt/local/bin/g++-mp-13 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/opt/local/Library/Frameworks/R.framework/Resources/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -lMacportsLegacySupport -Wl,-rpath,/opt/local/lib/libgcc -arch ppc -o minqa.so altmov.o bigden.o biglag.o bobyqa.o bobyqb.o lagmax.o minqa.o newuoa.o newuob.o prelim.o rescue.o trsapp.o trsbox.o trstep.o uobyqa.o uobyqb.o update.o updatebobyqa.o WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger -lMacportsLegacySupport -lgfortran -lef_ppc -F/opt/local/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
ld: file not found: WARNING:
collect2: error: ld returned 1 exit status
make: *** [minqa.so] Error 1
Nothing related to i386. Sorry, I just now reached it.
This must be fixed ASAP, of course, I will look into this now.
comment:5 Changed 7 months ago by barracuda156
Likely upstream has broken something in R itself, which is rather upsetting.
comment:6 Changed 7 months ago by barracuda156
Replying to ryandesign:
And it's not the only case.
Okay, I do not yet know why, but perhaps I know what is broken:
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
This fails to work correctly now. Since the packages themselves are not changed, it is likely broken in R 4.4.0. Though not impossible that elsewhere, just very few packages use this odd invocation for ldflags.
comment:7 Changed 7 months ago by barracuda156
I reverted to an older version of R-Rcpp, and the error remained. So it is either R itself or still R-Rcpp, but triggered by these warnings which were introduced in R 4.4.0.
UPD. Let's see if the upstream of R-Rcpp could help us: https://github.com/RcppCore/Rcpp/issues/1302
comment:8 follow-up: 13 Changed 7 months ago by barracuda156
So we have a fix now, but I need to know which packages fail, since it has to be fixed on packages' side. Is there a way to find that out from buildbots' results without peeping into every log?
comment:9 Changed 7 months ago by barracuda156
Warnings introduces into R in https://github.com/wch/r-source/commit/cd283240e413e01bd12838fb83673689972af5c0 (link to the mirror).
comment:10 Changed 7 months ago by barracuda156
We may have three issues here :)
- A bug in
startup.c(?) in R, which uses wrong types when determining memory limits. It also seems to use Linux defines for macOS.
Something like this will work, perhaps: https://github.com/wshanks/qiskit-aer/commit/11f6afa311ba609eeb3bca37ed01b797076739f9
But with the fixed type MinMaxVSize (which R source uses).
This perhaps leads to silly warnings being set in the first place. So even when starting R now,
36-170% /opt/local/bin/R WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger R version 4.4.0 (2024-04-24) -- "Puppy Cup" Copyright (C) 2024 The R Foundation for Statistical Computing Platform: powerpc-apple-darwin10.0.0d2 (32-bit)
- A bug somewhere, which interprets that as objects to pass to the linker. It is probably in
Rcpp, however the position of upstream is thatRcpp:::LdFlags()should not be used as deprecated a decade ago.
It should be easier to fix this in R to get rid of the warning string, though it will leave the second bug unfixed – but it won't affect us.
- Packages which use a deprecated call – but there are apparently many of such, we cannot bother fixing each one.
comment:11 Changed 7 months ago by barracuda156
Ticket with R upstream: https://bugs.r-project.org/show_bug.cgi?id=18713
I will make a PR with a fix now.
comment:12 Changed 7 months ago by barracuda156
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:13 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
Replying to barracuda156:
So we have a fix now, but I need to know which packages fail, since it has to be fixed on packages' side. Is there a way to find that out from buildbots' results without peeping into every log?
I report problems as I happen to notice them, usually because a build failure just happened on the buildbot while I was looking at the waterfall. We don't have a way to find all ports that failed due to a particular error message. Buildbot build information is collected by the ports web site, for example at https://ports.macports.org/all_builds/ , but the ports web site does not offer an API for retrieving that information.
comment:14 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)
We do keep track of which ports failed to build in each builder's failcache directory so I rescheduled builds of every failed R port which should appear here:
https://build.macports.org/builders/ports-10.6_i386-watcher/builds/58058
comment:15 Changed 7 months ago by barracuda156
Unfortunately, the issue seems not to be resolved on buildbots.
Example with R-stringfish:
https://build.macports.org/builders/ports-10.6_i386-builder/builds/164395/steps/install-port/logs/stdio
This is odd, since it does seem to have resolved it for me.
There is a hard solution of patching out the call which triggers this, but gonna be ugly and time-consuming.
comment:16 Changed 7 months ago by barracuda156
Well, we could obviously revert a commit which introduces these warnings for i386 builds of R. That shall solve the practical problem, but then the patch has to be carried over.
UPD. FWIW, on ppc the error does not occur now. Just tested on Rosetta, R starts up normally now:
macmini:~ svacchanda$ R R version 4.4.0 (2024-04-24) -- "Puppy Cup" Copyright (C) 2024 The R Foundation for Statistical Computing Platform: powerpc-apple-darwin10.8.0 (32-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R.
comment:17 Changed 7 months ago by barracuda156
UPD2. So it is fixed for GCC builds (including i386), but not for Clang builds. What do you think, just revert a problematic commit for now, when clang is used on x86 32-bit?
Replying to ryandesign:
It is very weird indeed: compiler takes
WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already larger WARNING: too small maximum for v(ector heap)size '0' ignored, the current usage 64M is already largeras a set of arguments.