Your Makevar.site is incorrect. Replace
CXX11 = $CXX
with
CXX11 = $(CXX)
$CXX only expands the macro 'C', not 'CXX'. Since C is not defined $CXX
expands to XX.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Tue, Jun 16, 2020 at 12:39 PM Thell Fowler <tbfowler4 at gmail.com> wrote:
Windows 10 Pro 2004 19041.329
WSL Version 2
Linux DESKTOP-K8EN726 4.19.104-microsoft-standard #1 SMP Wed Feb 19
06:37:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal
Sys.setenv("RunAllRcppTests"="yes")
Sys.setenv("RunVerboseRcppTests"="yes")
tinytest::test_package("Rcpp")
-------------------------------------------
using: gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
*[1] "All ok, 1541 results"*
-------------------------------------------
using: Ubuntu clang version
10.0.1-++20200529022935+a634a80615b-1~exp1~20200529003545.39
with Makevars.site containing:
CC = clang
CXX = clang++
CFLAGS = -g -O2
CXXFLAGS = -g -O2
CXX11 = $CXX
CXX14 = $CXX
CXX17 = $CXX
CXX20 = $CXX
CXX1X = $CXX
Halted with:
Running test_stack.R.................. 0 tests /bin/bash: XX:
command not found
make: *** [/usr/lib/R/etc/Makeconf:176: stack.o] Error 127
XX -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG
-DRCPP_USE_UNWIND_PROTECT -I"/usr/local/lib/R/site-library/Rcpp/include"
-I"/usr/local/lib/R/site-library/Rcpp/tinytest/cpp" -fpic -g -O2
-fdebug-prefix-map=/build/r-base-Do_dS_/r-base-4.0.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -g -c stack.cpp -o stack.o
Error in Rcpp::sourceCpp("cpp/stack.cpp") :
Error 1 occurred building shared library.
I'm fairly sure the issue is on my setup but not quite sure what it is
from a quick glance.
-------------------------------------------
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 4
minor 0.0
year 2020
month 04
day 24
svn rev 78286
language R
version.string R version 4.0.0 (2020-04-24)
nickname Arbor Day
On Tue, Jun 16, 2020 at 8:47 AM Dirk Eddelbuettel <edd at debian.org> wrote:
Hi all,
Below is an ascii version of what I blogged yesterday, proper URL links
are
at http://dirk.eddelbuettel.com/blog/2020/06/15#rcpp_1.0.5_testing
Help in testing, particular on unusual hardware or compiler choices, or
particularly old releases of OS, compiler, R, ... would be welcome. I am
quite confident the release will be fine on CRAN and standard systems.
But for use on less standard setups, the time to test is now. If you are
a
user of Rcpp under such circumstance, please help now in testing and
reporting issues, if any are seen.
Thanks, Dirk
Mon, 15 Jun 2020
Rcpp 1.0.5 in two+ weeks: Please help test
rcpp logo
With the current four-month release cycle, the next Rcpp release is
due in
July following the 1.0.4 release in March. Just prior to the 1.0.4
release
I had asked this:
It would be particularly beneficial if those with “unsual†build
dependencies tested it as we would increase overall coverage beyond
what
I get from testing against 1800+ CRAN packages. BioConductor would
also
be welcome.
but only on the rcpp-devel list, and only about a good week prior to
the
release.
I remain rather disappointed and disillusioned about what happened
after
1.0.4 was released. Two PRs in that release were soon seen to have
side
effects on more ‘marginal’ test systems, precisely what added testing
could have revealed. An additional issue arose from changes in R’s
make
system, which is harder to anticipate or test. Each and every
infelicity
was fixed within a day or so, and we always make candidate releases
available—the current Rcpp as of this writing is 1.0.4.12 meaning
twelve
microreleases were made since 1.0.4. And those microreleases are
always
available for normal download and install.packages use via the Rcpp
drat
repository accessible to all. So it was truly troubling to see some,
especially those with experience in setting up or running testing / ci
platforms, pretend to be unable to access, install, and provide these
for
their own tests, or the tests of their users. It just doesn’t pass a
basic
logic test: it takes a single call to install.packages(), or, even
more
easily, a single assignment of an auxiliary repo. All told this was a
rather sad experience.
So let’s try to not repeat this. If you, or maybe users of a build or
ci
system you maintain, rely on Rcpp, and especially if you do so on
systems
outside the standard CRAN grid of three OSs and the triplet of
“previous,
current, next†releases of R, then please help by testing. I maitain
these
release as a volunteer, unpaid at that, and I simply cannot expand to
more
systesm. We take reverse dependency check seriously (and I just run
two
taking about a day each) but if you insist on building on stranger
hardware or much older releases it will be up to you to ensure Rcpp
passes. We prep for CRAN, and try our best to pass at CRAN. For
nearly a
dozen years.
To install the current microrelease from the Rcpp drat repository,
just do
install.packages("Rcpp", repos="https://rcppcore.github.io/drat")
That is all there is to it. You could even add the Rcpp drat
repository to
your repository list.
Rcpp has become successful because so many people help with
suggestions,
documentation, and code. It is used by (as of today) 1958 CRAN
packages,
205 BioConductor packages, and downloaded around a million times per
month. So if you can, please help now with some more testing.
If you like this or other open-source work I do, you can now sponsor
me at
GitHub. For the first year, GitHub will match your contributions.
This post by Dirk Eddelbuettel originated on his Thinking inside the
box
blog. Please report excessive re-aggregation in third-party for-profit
settings.
/code/rcpp | permanent
link
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org