[R-pkg-devel] [Extern] Re: Re: Problem building package depending on third party c++ source library.

[Nils Lüschow]

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 <nilue103 using 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).
>