Compilation error on Slackware Linux with gcc 14

[xbasics]

Tried compiling v1.0.0 within R environment as part of installation and getting the following error. Installed the latest version of the re2 package without any issue, yet there seems to be a problem with the one included.

duckdb/third_party/re2/re2/prog.cc: In member function ‘const void* duckdb_re2::Prog::PrefixAccel_FrontAndBack(const void*, size_t)’:
duckdb/third_party/re2/re2/prog.cc:1146:45: error: ‘prefix_front_’ was not declared in this scope
1146 | const m256i f_set1 = mm256_set1_epi8(prefix_front);
| ^~~~~~~~~~~~~
duckdb/third_party/re2/re2/prog.cc:1147:45: error: ‘prefix_back’ was not declared in this scope; did you mean ‘prefix_size’?
1147 | const _m256i b_set1 = mm256_set1_epi8(prefix_back);
| ^~~~~~~~~~~~
| prefix_size
make: *** [/usr/lib64/R/etc/Makeconf:200: duckdb/third_party/re2/re2/prog.o] Error 1
ERROR: compilation failed for package ‘duckdb’

• removing ‘~/.R_LIBS/duckdb’
• restoring previous ‘~/.R_LIBS/duckdb’
  Warning in install.packages :
  installation of package ‘duckdb’ had non-zero exit status

The downloaded source packages are in
‘/tmp/RtmpQngRjl/downloaded_packages’

[krlmlr]

Thank you. What OS and version is this, what compiler are you using? Can you compile the duckdb sources at https://github.com/duckdb/duckdb ?

[xbasics]

Thanks for your reply! I'm running Linux (Slackware current) using GCC 14.1.0 w/ GLibc 2.39 on an AMD Ryzen 7 4800H processor. In terms of R environment, I'm using R 4.4.1. I compile R on my local machine using the following C/CXX flags, which are kept was part of the subsequent package installations.

-O3 -fPIC -march=native -pipe

In terms of compiling duckdb-r sources by themselves, I did clone the (current) main branch and compile it simply running make and encountered the following error (w/ jemalloc and duckdb_je_buferror).

[ 49%] Building C object extension/jemalloc/jemalloc/CMakeFiles/jemalloc.dir/src/malloc_io.c.o
/home/x/duckdb/extension/jemalloc/jemalloc/src/malloc_io.c: In function ‘duckdb_je_buferror’:
/home/x/duckdb/extension/jemalloc/jemalloc/src/malloc_io.c:107:16: error: returning ‘char *’ from a function with return type ‘int’ makes integer from pointer without a cast [-Wint-conversion]
107 | return strerror_r(err, buf, buflen);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
gmake[3]: *** [extension/jemalloc/jemalloc/CMakeFiles/jemalloc.dir/build.make:552: extension/jemalloc/jemalloc/CMakeFiles/jemalloc.dir/src/malloc_io.c.o] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:7952: extension/jemalloc/jemalloc/CMakeFiles/jemalloc.dir/all] Error 2
gmake[1]: *** [Makefile:136: all] Error 2
gmake[1]: Leaving directory '/home/x/duckdb/build/release'
make: *** [Makefile:283: release] Error 2

The duckdb_je_buferror function returns an int, but strerror_r(err, buf, buflen) is returning a char *. This error was just simply fixed by uncommenting the define instruction at 485...

/*

• Defined if strerror_r returns char * if _GNU_SOURCE is defined.
  */
  #define JEMALLOC_STRERROR_R_RETURNS_CHAR_WITH_GNU_SOURCE

...of header file extension/jemalloc/jemalloc/include/jemalloc/internal/jemalloc_internal_defs.h and recompiling.

Also compiled both v1.0.0 and v1.0.0.9000 using R CMD INSTALL . again from the command-line with both resulting in the same originally identified error.

[krlmlr]

Thanks. Can you please raise this with https://github.com/duckdb/duckdb ?

[xbasics]

Appreciate your reply! Note that when compiling duckdb/duckdb v1.0.0 I don't encounter any errors. It's only when I compile duckdb/duckdb-r. So, you're saying that this nonetheless should be raised with them?

[vishalbelsare]

Facing same error trying to install duckdb in R under Arch Linux.

[krlmlr]

Thanks, Alex. I missed that part when you said that the upstream library compiles without error.

Is there a chance I can reproduce this locally with Docker?

[xbasics]

Sorry for the late reply. Probably all you need is a Linux distro making sure you have the latest versions of GCC (14.1.0) and glibc (2.39). As previously mentioned, I'm also using the latest version of R (v4.4.1).

Then again, you could also go with the latest version of Slackware and then updating it using the "current" channel...

https://alien.slackbook.org/blog/my-docker-packages-for-slackware-current/

Installing Slackware is really straight-forward. In case of doubt, install everything and yet it won't be incredibly big.
According to [vishalbelsare], he's having the same issue with Arch Linux, so that's another avenue to try.

There is really nothing special about my installation, other than Slackware-current, which runs very up-to-date versions of software.

BTW, I just tried the latest version of the duckdb package (v1.0.0-2) and still getting the same error. v0.10.0 of this package works fine.

[david-cortes]

This issue appears to have been an error in the RE2 library when AVX2 instructions are enabled:
duckdb/duckdb#12344

It is fixed in the current master branch, so compilation succeeds if installing the R package for duckdb from GitHub, but fails when installing from CRAN.

Odd that the CRAN checks did not catch it, but would be ideal if this fix could be added to the CRAN 1.0 release, given that it might be a while until there's a next version release of core DuckDB.

[krlmlr]

Thanks for the heads-up. The change in 7353b83 would apply to the current CRAN version 1.0.0-2, but given that the next regular duckdb CRAN release will contain it, I'd rather not make the effort.

@david-cortes: Can you confirm that 7353b83 works but its predecessor fbbfe5a fails?

[vishalbelsare]

This issue appears to have been an error in the RE2 library when AVX2 instructions are enabled: duckdb/duckdb#12344

It is fixed in the current master branch, so compilation succeeds if installing the R package for duckdb from GitHub, but fails when installing from CRAN.

Odd that the CRAN checks did not catch it, but would be ideal if this fix could be added to the CRAN 1.0 release, given that it might be a while until there's a next version release of core DuckDB.

Yes, it worked for me when I installed from Github, so definitely odd that the CRAN had marked their build as OK.

[krlmlr]

Thanks, Vishal. Can you also confirm that 7353b83 works but its predecessor fbbfe5a fails?

[david-cortes]

Thanks, Alex. I missed that part when you said that the upstream library compiles without error.

Is there a chance I can reproduce this locally with Docker?

It's a matter of adding -mavx2 or higher to the compilation arguments. For example, a file ~/.R/Makevars like this would do:

CXXFLAGS += -mavx2
CXX11FLAGS += -mavx2
CFLAGS += -mavx2