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

Reply via email to