duckdb: [R] Package installation on aarch64 fails for v0.3.2

Will be fixed with the next minor release of R (4.2.2 4.3.0^1) as *PICFLAGS are now will be set to -fPIC for aarch64.

Cross reference: https://bugs.r-project.org/show_bug.cgi?id=18326

Thanks for tagging me in this thread – won’t claim I read every one of your many messages in detail. The use of -fpic vs -fPIC is something governed by R’s own configure which Kurt Hornik looks after who is generally quite responsive. We had a recent bug report against the R package where an update was needed for ‘alpha’, the patch is still applied in 4.1.3 but has been added to r-devel after we got it and forwarded it. So if this is a Debian-on-aarch issue in general, it should bite you in more packages than just duckdb. @hannes is quite right that he is bystander here: an R package just “receives” these flags. You could test this locally by editing /etc/R/Makeconf on the failing system and see if it helps.

[ I have been meaning to turn LTO on as well but am a little fearful that we then end up with lots of reports like this. So so far I just follow along to what R Core and Debian default. ]

Simon Urbanek, 2022-04-27 09:59:44 UTC

Just a quick comment: please note that this is not an issue for R since it doesn’t get anywhere close to the limit, so this is really low priority (if an issue at all). Packages with exceptionally large sizes can handle their own flags. Some further research suggests the overrides are intentional due to performance issues on some platforms so you’d likely have to convince experts in that field that that such chage does not cause more harm that good. Given the earlier comments I’m certainly not touching this.

– https://bugs.r-project.org/show_bug.cgi?id=18326#c14

(Just for completeness, the Debian packages does nothing “opionionated” itself here. So if on a particular platform we feel a -fpic needs to be a -fPIC (or vice versa) it is really upstream we need to talk to. I can (and have) test-drive a patch before talking about it to upstream, but I don’t have the hardware platform so at the end of the day the easiest / cleanest is just for for @benz0li to locally modify his setup, test that everything works and then propose something. Now, we should probably get out of this thread here as it all is getting a wee bit tangential for duckdb.)

Error when building v0.3.3 from source:

[...]
g++ -std=gnu++11 -shared -L/usr/local/lib/R/lib -L/usr/local/lib -o duckdb.so rapi.o database.o connection.o statement.o register.o scan.o utils.o altrep.o types.o cpp11.o -L/usr/local/src/duckdb/build/debug/src -lduckdb_static -L/usr/local/src/duckdb/build/debug/extension/parquet -lparquet_extension -ldl -L/usr/local/src/duckdb/build/debug/third_party/fmt -lduckdb_fmt -L/usr/local/src/duckdb/build/debug/third_party/libpg_query -lduckdb_pg_query -L/usr/local/src/duckdb/build/debug/third_party/re2 -lduckdb_re2 -L/usr/local/src/duckdb/build/debug/third_party/miniz -lduckdb_miniz -L/usr/local/src/duckdb/build/debug/third_party/utf8proc -lduckdb_utf8proc -L/usr/local/src/duckdb/build/debug/third_party/hyperloglog -lduckdb_hyperloglog -L/usr/local/src/duckdb/build/debug/third_party/fastpforlib -lduckdb_fastpforlib -lpthread -L/usr/local/src/duckdb/build/debug/extension/parquet -lparquet_extension -L/usr/local/src/duckdb/build/debug/extension/icu -licu_extension -L/usr/local/src/duckdb/build/debug/extension/visualizer -lvisualizer_extension -L/usr/local/lib/R/lib -lR
register.o: in function `void std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag)':
/usr/include/c++/10/bits/basic_string.tcc:206:(.text+0x14): relocation truncated to fit: R_AARCH64_LD64_GOTPAGE_LO15 against symbol `__stack_chk_guard@@GLIBC_2.17' defined in .data.rel.ro section in /lib/ld-linux-aarch64.so.1
/usr/bin/ld: /usr/include/c++/10/bits/basic_string.tcc:206: warning: too many GOT entries for -fpic, please recompile with -fPIC
collect2: error: ld returned 1 exit status
make: *** [/usr/local/lib/R/share/make/shlib.mk:10: duckdb.so] Error 1
ERROR: compilation failed for package ‘duckdb’
* removing ‘/usr/local/lib/R/site-library/duckdb’

By the way, the same error when building v0.3.2 from source.

@eddelbuettel I don’t think the R package for Debian on aarch64 needs to be changed. The following 284 packages (including duckdb-0.3.1) build fine with *PICFLAGS = -fpic: packages.csv

FYI @eitsupi for future linux/arm64/v8 builds of https://github.com/rocker-org/rocker-versioned2. I currently use the following workaround when building on aarch64:

if [ "$(dpkg --print-architecture)" = "arm64" ]; then
  cp -a /usr/local/lib/R/etc/Makeconf /usr/local/lib/R/etc/Makeconf.bak;
  sed -i 's/fpic/fPIC/g' /usr/local/lib/R/etc/Makeconf;
  install2.r --error --skipinstalled duckdb;
  mv /usr/local/lib/R/etc/Makeconf.bak /usr/local/lib/R/etc/Makeconf;
else
  install2.r --error --skipinstalled duckdb;
fi

With the following set in ~/.R/Makevars the package builds successfully:

ALL_CXXFLAGS =  $(PKG_CXXFLAGS) -fPIC $(SHLIB_CXXFLAGS) $(CXXFLAGS)

Thanks for all the feedback.

Well yes, that’s the problem then. As the compile log says, this flag should be -fPIC instead. But we don’t control that, whoever configures the R installation does.

That’s very odd there were only minute changes…