Uploaded image for project: 'Apache Arrow'
  1. Apache Arrow
  2. ARROW-9616

[C++] Support LTO for R

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.0.0
    • None
    • C++, R

    Description

      The next version of R might enable LTO on Windows, i.e. R packages will be compiled with -flto by default. This works out of the box for most packages, but for arrow, the linker crashes as below.

       C:/rtools40/mingw64/bin/g++ -shared -O2 -Wall -mfpmath=sse -msse2 -mstackrealign -flto -s -static-libgcc -o arrow.dll tmp.def array.o array_from_vector.o array_to_vector.o arraydata.o arrowExports.o buffer.o chunkedarray.o compression.o compute.o csv.o dataset.o datatype.o expression.o feather.o field.o filesystem.o imports.o io.o json.o memorypool.o message.o parquet.o py-to-r.o recordbatch.o recordbatchreader.o recordbatchwriter.o scalar.o schema.o symbols.o table.o threadpool.o -L../windows//lib-8.3.0/x64 -L../windows//lib/x64 -lparquet -larrow_dataset -larrow -lthrift -lsnappy -lz -lzstd -llz4 -lbcrypt -lpsapi -lcrypto -lcrypt32 -lws2_32 -LC:/PROGRA~1/R/R-devel/bin/x64 -lR
       lto1.exe: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:153
       libbacktrace could not find executable to open
       Please submit a full bug report,
       with preprocessed source if appropriate.
       See <[https://github.com/r-windows]> for instructions.
       lto-wrapper.exe: fatal error: C:\rtools40\mingw64\bin\g++.exe returned 1 exit status
       compilation terminated.
       C:/rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: error: lto-wrapper failed
      

      You can reproduce this in R on Windows for example like so:

      dir.create("~/.R")
      writeLines("CPPFLAGS=-flto", file = "~/.R/Makevars")
      install.packages("arrow", type = 'source')
      

      I am not sure if this is a bug in the toolchain, or in arrow. I tried with both gcc-8.3.0 and gcc-9.3.0, and the result is the same. I did find this issue in another project which suggests to enable `INTERPROCEDURAL_OPTIMIZATION` in cmake, when mixing lto code with non-lto code (which is the case when we only build the r bindings with lto, but not the c++ library).

      Attachments

        Activity

          People

            Unassigned Unassigned
            jeroenooms Jeroen
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 3h 40m
                3h 40m