Skip to content

[R-pkg-devel] gcc-san fail with s2 package

3 messages · Elias T. Krainski, Ivan Krylov

Original
Elias T. Krainski
# 
Let me try to clarify the issue. An earlier version has failed a memory
sanitize check. I was able to solve it. But, at the same time, some
dependency was added, which includes the 's2' package but is not a direct
dependency.

What seems to happen now is that the gcc-san special check is performed in
an environment where all the dependency is compiled, but it fails to
compile 's2', as far as I can see from
https://win-builder.r-project.org/incoming_pretest/graphpcor_0.1.19_20260131_125536/specialChecks/gcc-san/

My current approach is to do a workaround to remove such a dependency. I
had to do it also to another one recently because of a similar issue (
https://win-builder.r-project.org/incoming_pretest/graphpcor_0.1.17_20260126_215413/specialChecks/clang-san/
)

On Sat, 31 Jan 2026 at 22:21, Elias T. Krainski <eliaskrainski at gmail.com>
wrote:

  
  


  


    

    

      
      

        


  

        

      Ivan Krylov
    

    

      
      #
    

  


  

      
? Tue, 3 Feb 2026 14:34:14 +0300
"Elias T. Krainski" <eliaskrainski at gmail.com> ?????:

            

      
      
      
    

        
Very annoying situation to be in. g++ fails to compile these source
files because of the -fsanitize=undefined flag. This is reproducible in
the rocker/r-devel-san container, or by hand in a Debian testing
installation.

This is probably a compiler bug, although it could also be a bug in the
libabsl-dev version distributed in Debian testing. If you have the
time, try reducing the example to a minimal file that fails to compile
with constexpr-related errors when -fsanitize=undefined is added, then
reporting it to the GCC developers, or at least asking in the #gcc
channel on libera.chat. I can try to find the time to help with this
later, but not right now.

's2' developers seem to be aware of this [*], but there isn't much to
fix in the package source code.

[*] https://github.com/r-spatial/s2/issues/270#issuecomment-2881978818

  
    

      
      
    

  


  


      

    

    
10 days later

    

      
      

        


  

        

      Ivan Krylov
    

    

      
      #
    

  


  

      
? Tue, 3 Feb 2026 15:00:05 +0300
Ivan Krylov via R-package-devel <r-package-devel at r-project.org> ?????:

            

      
      
      
    

        
After a different package maintainer complained, they are now working
on the fix for this issue:
https://github.com/r-spatial/s2/issues/293
https://github.com/r-spatial/s2/pull/295

This is actually a GCC bug and not just a C++17/C++20 constexpr
problem: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962>

(Once again, many thanks to Gentoo developer sam_ and GCC developer
Arsen for pointing out the exact bug report from a vague description of
the problem!)

Since the function pointer comparison against nullptr in constexpr
context lives in the system-provided header file, the s2 maintainers
will probably have to build the full libabsl themselves in order to
work around this problem.