This compiler error was apparently in a gcc update from last year,
previously this would have been a warning. Apparently the gcc version in
my wsl working environment was older and therefore I did not encounter
it. I just removed the "const" and that fixed it (as it was const
before, there shouldn't be a point where this variable is changed, so I
guess it shouldn't cause any problems if I do not touch the Gecode
library any further).
With this and some minor Makevars adjustments I got Gecode to compile
both separately in the CRAN Debian testing container as well as in
conjunction with R CMD "check".
Most remaining warnings are easy to deal with, however, one seems to be
more problematic:
* checking for GNU extensions in Makefiles ... WARNING
Found the following file(s) containing GNU extensions:
src/gcd/Makefile
src/gcd/Makefile.in
src/gecode_untouched/Makefile.in
Portable Makefiles do not use GNU extensions such as +=, :=, $(shell),
$(wildcard), ifeq ... endif, .NOTPARALLEL See section ‘Writing portable
packages’ in the ‘Writing R Extensions’ manual.
So there are definitely multiple occurences of such extensions in the
Gecode Makefile. Since it is, unfortunately, quite extensive I would
rather not have to rewrite too much of it (also because I do not really
know too much about more advanced Makefiles). So the question would be
how unportable it really is in its current state. I have compiled Gecode
on multiple different Windows and Linux systems without too much hassle
so far, which is why I wonder whether it is really all that bad (after
all the library itself was written to run on Linux, Windows and MacOS).
Best regards,
Nils
Am 03.06.2025 um 10:04 schrieb Ivan Krylov:
On Sat, 24 May 2025 17:07:06 +0200
Nils Lüschow <nilue...@hhu.de> wrote:
Regarding the "mismatched-new-delete" warning I am also relatively
sure that this is actually a false positive. Taking a look into the
stack-trace, the new and delete operators are actually overloaded
with functions that internally use malloc and free, hence, there is
no mismatch
You're right, I see now that the call to free() is inlined into the
operator delete. This might be the same GCC bug as reported at
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100485>, but I've been
wrong about finding the exact problem before.
Generally, R CMD check will produce a NOTE if it sees you disabling a
compiler warning, but the compiler is in the wrong here, and a NOTE is
better than a WARNING. Still, it's best to have a package pass R CMD
check without even NOTEs because those don't need to be re-checked by a
human upon updates. Perhaps you could ask on Libera.Chat's #gcc channel
about possible workarounds? Sorry for not giving a more definitive
answer.
I've tried compiling the package on a Debian testing container, which
is the OS that runs the incoming package checks, and encountered even
more problems. Now gecode doesn't build at all, manually with
'./configure && make' or as part of the R package:
In file included from gecode/set/rel.cpp:39:
In file included from ./gecode/set/int.hh:296:
./gecode/set/int/weights.hpp:127:14: error: no viable overloaded '='
127 | elements = elements0; weights = weights0;
| ~~~~~~~~ ^ ~~~~~~~~~
./gecode/kernel/data/shared-array.hpp:53:9: note: candidate function (the implicit
copy assignment operator) not viable: 'this' argument has type 'const
SharedArray<int>', but
method is not marked const
53 | class SharedArray : public SharedHandle {
| ^
In file included from gecode/set/rel.cpp:39:
In file included from ./gecode/set/int.hh:296:
./gecode/set/int/weights.hpp:127:35: error: no viable overloaded '='
127 | elements = elements0; weights = weights0;
| ~~~~~~~ ^ ~~~~~~~~
./gecode/kernel/data/shared-array.hpp:53:9: note: candidate function (the implicit
copy assignment operator) not viable: 'this' argument has type 'const
SharedArray<int>', but
method is not marked const
53 | class SharedArray : public SharedHandle {
| ^
Additionally, gecode's ./configure wants to add --std=c++11 to the
compiler command line. I don't know if linking C++20 and C++11 code
would cause ABI problems, but it might better to configure gecode with
--enable-cpp11=no (since Makevars already gives the compatible standard
flag to ./configure).
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel