Windows build is broken again

[meztez]

I have no intention of fixing it for the moment.

[emanuele-depaoli-sdg]

Hi Bruno,
can you please give me some guidance on where to start to fix the issue?

Thank you,
Emanuele.

[meztez]

Try to compile it? Something about the linker prevents it from building on windows. Rtools had significant changes from the last time I used it on windows and it does not compile anymore. I did not dig far to resolve it.

[emanuele-depaoli-sdg]

The error is

 C:\rtools42\x86_64-w64-mingw32.static.posix\bin/ld.exe: google/api/resource.pb.o:resource.pb.cc:(.rdata$.refptr.__emutls_v._ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E[.refptr.__emutls_v._ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E]+0x0): undefined reference to "__emutls_v._ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E"
collect2.exe: error: ld returned 1 exit status 

I created a Makevars.win file that emulates the compiler flag and options used in Linux, where compilation works:

# Default make file;
PKG_CPPFLAGS = -DNOMINMAX -maes -msse4.1 -DNOMINMAX -maes -msse4.1 -DNOMINMAX -IC:/rtools42/mingw64/bin/../include -DSTRICT_R_HEADERS
PKG_CXXFLAGS = -I. -D_WIN32_WINNT=0x600
PKG_LIBS = -LC:/rtools42/mingw64/bin/../lib -lprotobuf -pthread -lgrpc++ -lgrpc -laddress_sorting -lre2 -lupb -lcares -lz -lgpr -lssl -lcrypto -labsl_raw_hash_set -labsl_hashtablez_sampler -labsl_hash -labsl_city -labsl_low_level_hash -labsl_random_distributions -labsl_random_seed_sequences -labsl_random_internal_pool_urbg -labsl_random_internal_randen -labsl_random_internal_randen_hwaes -labsl_random_internal_randen_hwaes_impl -labsl_random_internal_randen_slow -labsl_random_internal_platform -labsl_random_internal_seed_material -labsl_random_seed_gen_exception -labsl_statusor -labsl_status -labsl_cord -labsl_cordz_info -labsl_cord_internal -labsl_cordz_functions -labsl_exponential_biased -labsl_cordz_handle -labsl_bad_optional_access -labsl_strerror -labsl_str_format_internal -labsl_synchronization -labsl_graphcycles_internal -labsl_stacktrace -labsl_symbolize -labsl_debugging_internal -labsl_demangle_internal -labsl_malloc_internal -labsl_time -labsl_civil_time -labsl_strings -labsl_strings_internal -labsl_base -labsl_spinlock_wait -labsl_int128 -labsl_throw_delegate -labsl_time_zone -labsl_bad_variant_access -labsl_raw_logging_internal -labsl_log_severity -lcrypt32 -lws2_32 -limagehlp
CXX_STD = CXX17

# Obtain the object files
OBJECTS=google/api/field_behavior.pb.o google/api/http.pb.o google/api/launch_stage.pb.o google/api/resource.pb.o google/cloud/bigquery/storage/v1/arrow.pb.o google/cloud/bigquery/storage/v1/avro.pb.o google/cloud/bigquery/storage/v1/table.pb.o google/api/annotations.pb.o google/api/client.pb.o google/cloud/bigquery/storage/v1/protobuf.pb.o google/cloud/bigquery/storage/v1/stream.pb.o google/rpc/status.pb.o google/cloud/bigquery/storage/v1/storage.pb.o google/cloud/bigquery/storage/v1/storage.grpc.pb.o bqs.o RcppExports.o

strippedLib: $(SHLIB)
	if test -e "/usr/bin/strip"; then /usr/bin/strip --strip-unneeded $(SHLIB); fi

.phony: strippedLib

Compared to Linux's Makevars, I've just deleted -lrt from PKG_LIBS , added -D_WIN32_WINNT=0x600 to PKG_CXXFLAGS and -lcrypt32 -lws2_32 -limagehlp to PKG_LIBS, as you do in tools/config/configure.R .

Using this Makevars.win, the errors are undefined reference to "absl::lts_20230125" .
Indeed, in Windows, the flag -std=gnu++17 is missing when calling

g++ -shared -s -static-libgcc -o bigrquerystorage.dll tmp.def google/api/field_behavior.pb.o google/api/http.pb.o google/api/launch_stage.pb.o google/api/resource.pb.o google/cloud/bigquery/storage/v1/arrow.pb.o google/cloud/bigquery/storage/v1/avro.pb.o google/cloud/bigquery/storage/v1/table.pb.o google/api/annotations.pb.o google/api/client.pb.o google/cloud/bigquery/storage/v1/protobuf.pb.o google/cloud/bigquery/storage/v1/stream.pb.o google/rpc/status.pb.o google/cloud/bigquery/storage/v1/storage.pb.o google/cloud/bigquery/storage/v1/storage.grpc.pb.o bqs.o RcppExports.o -LC:/rtools42/mingw64/bin/../lib -lprotobuf -pthread -lgrpc++ -lgrpc -laddress_sorting -lre2 -lupb -lcares -lz -lgpr -lssl -lcrypto -labsl_raw_hash_set -labsl_hashtablez_sampler -labsl_hash -labsl_city -labsl_low_level_hash -labsl_random_distributions -labsl_random_seed_sequences -labsl_random_internal_pool_urbg -labsl_random_internal_randen -labsl_random_internal_randen_hwaes -labsl_random_internal_randen_hwaes_impl -labsl_random_internal_randen_slow -labsl_random_internal_platform -labsl_random_internal_seed_material -labsl_random_seed_gen_exception -labsl_statusor -labsl_status -labsl_cord -labsl_cordz_info -labsl_cord_internal -labsl_cordz_functions -labsl_exponential_biased -labsl_cordz_handle -labsl_bad_optional_access -labsl_strerror -labsl_str_format_internal -labsl_synchronization -labsl_graphcycles_internal -labsl_stacktrace -labsl_symbolize -labsl_debugging_internal -labsl_demangle_internal -labsl_malloc_internal -labsl_time -labsl_civil_time -labsl_strings -labsl_strings_internal -labsl_base -labsl_spinlock_wait -labsl_int128 -labsl_throw_delegate -labsl_time_zone -labsl_bad_variant_access -labsl_raw_logging_internal -labsl_log_severity -lcrypt32 -lws2_32 -limagehlp -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib/x64 -LC:/rtools42/x86_64-w64-mingw32.static.posix/lib -LC:/PROGRA~1/R/R-42~1.3/bin/x64 -lR

while it is not in Linux.

Hope that it makes any sense. My knowledge about C/C++ and their R integration is very limited.

[meztez]

Might be related : protocolbuffers/protobuf#12746

[meztez]

@emanuele-depaoli-sdg I've added the build flag -DPROTOBUF_USE_DLLS, and it now compiles.

Let me know, if this solved it for you too.

thanks

[emanuele-depaoli-sdg]

Thank you Bruno, now it compiles but R crashes when calling bqs_table_download. The error is

[emanuele-depaoli-sdg]

I think it can be related to this
msys2/MINGW-packages#6097

[meztez]

All right, I'm giving up for now. You can manually install previous version of grpc along with matching module 1.51 should still build. Currently, 1.55.1 in the repo, protobuf 23.4, abseil 20230125 will not work.

[emanuele-depaoli-sdg]

Unfortunately I couldn't install grcp 1.51.0. I retrieved its PKGBUILD from old commits in msys2 repo but compilation fails with error:
ninja: build stopped: subcommand failed.

[emanuele-depaoli-sdg]

I found the packages already built here: https://repo.msys2.org/mingw/x86_64/
So I downgraded grpc to 1.51.1, protobuf to 21.10.1 and abseil to 20220623.1-2.
It compiles smoothly until the end, when it throws the error:

** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for 'bigrquerystorage' in inDL(x, as.logical(local), as.logical(now), ...):
 unable to load shared object 'C:/Users/depaolie/Documents/R/win-library/4.2/00LOCK-bigrquerystorage/00new/bigrquerystorage/libs/x64/bigrquerystorage.dll':
  LoadLibrary failure:  The specified module could not be found.

It's weird, my paths are set correctly and I dont have any issues with other packages

[meztez]

what do you get when you run ldd on the the bigrquerystorage.dll?

[emanuele-depaoli-sdg]

I tried to run ldd bigrquerystorage.dll on my WSL but it is not working. Should I use dependecy walker?

[meztez]

So I spent the last 10 hours trying to figure out what goes wrong on Windows.

I can get it to compile, I can create a client and authenticate. But I fail creating a read session.

There is a segmentation fault happening here:

bigrquerystorage/src/bqs.cpp

Line 115 in 913a549

grpc::Status status = stub_->

gdb gives me this, which is not super useful. The protoc compiler might be the problem? I'll wait for msys2 to update it and try again next year.

[New Thread 21716.0x5e64]
[New Thread 21716.0x5d18]
[New Thread 21716.0x5fdc]
warning: Critical error detected c0000374

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff7a74f3a3 in ntdll!RtlIsZeroMemory () from /c/WINDOWS/SYSTEM32/ntdll.dll

[gaborcsardi]

I believe that this is fixed now, at least for R 4.3.x and current R-devel. You need the latest version of Rtools32. (Notably, winget and choco do not install the latest version, and GHA also does not have the latest.)

We'll improve it some time next week, to work on earlier Rtools43, and possibly earlier R versions as well. In particular, we'll use this approach: main...jeroen:bigrquerystorage:main instead of my current one.