gcc
Closed this issue · 4 comments
This concerns packages
BNSP BPEC C50 CompRandFld Cubist HWxtest MigClim PBSddesolve PET
PwrGSD RDieHarder Rmpfr TTR VBLPCM actuar aucm bibtex bitrugs carfima
cec2005benchmark cleancall coxme cubature curl data.table deSolve
deTestSet dti eha epanet2toolkit fansi gensvm geometry gpg hdf5r hergm
keypress landscapemetrics latentnet lfe memisc mmap msm networkDynamic
pbdMPI pgmm phyclust phylocomr pomdp pop.wolf population randtoolbox
rootSolve samon smoof soobench topicmodels vctrs vetr weightedScores xts
which fail to install with gcc trunk which is due to be released as gcc 10.0.x early in 2020. It defaults to -fno-common, which stricter on some multiply-defined symbols -- see §1.6.4.1 of 'Writing R Extensions' in current R-devel.
See https://www.stats.ox.ac.uk/pub/bdr/gcc10/ for the logs, which will be linked from the CRAN results page under 'Additional issues'.
We expect the issues to also be seen when compiling with earlier versions of gcc using the (non-default) flag -fno-common: this has been confirmed for gcc 9 on Linux, and also for clang on macOS.
Please correct as soon as possible and before Jan 10 to safely retain on CRAN. (This is after the CRAN shutdown from Dec 20 to Jan 6.)
I found the following here: joshuaulrich/TTR@96176d1
All variable definitions need to be declared once, and defined once.
For whatever reason, this answer clicked for me: https://stackoverflow.com/a/12511340/271616
You should declare the variables, and be using
externto tell the compiler that the variables are defined somewhere else. Then in one source file you define the variables (i.e. the same as the declarations in the header file but without theexternkeyword).Now that all variables are only defined once, we can probably remove this chunk from xts.h:
#ifdef __cplusplus
extern "C" {
#endif
I would assume it is about the global variables defined in https://github.com/r-spatialecology/landscapemetrics/blob/master/src/cclabel_4.c and https://github.com/r-spatialecology/landscapemetrics/blob/master/src/cclabel_8.c...
I think @Nowosad is correct. I'll fix cclabel.
Until now I was not able to reproduce this, I'll try gcc9 next week.
Fixed with new CCL algorithm