#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 6 months ago by barracuda156
comment:2 follow-ups: 3 6 Changed 5 months ago by ryandesign (Ryan Carsten Schmidt)
comment:3 Changed 5 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.
- S. Perhaps, worth adding a tag for
i386and add other affected ports.
comment:4 Changed 5 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 5 months ago by barracuda156
Likely upstream has broken something in R itself, which is rather upsetting.
comment:6 Changed 5 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 5 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 5 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 5 months ago by barracuda156
Warnings introduces into R in https://github.com/wch/r-source/commit/cd283240e413e01bd12838fb83673689972af5c0 (link to the mirror).
comment:10 Changed 5 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 5 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 5 months ago by barracuda156
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:13 Changed 5 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 5 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 5 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 5 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.
comment:17 Changed 5 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.