arrow: Linking error: `Symbol not found: __ZN5arrow12ArrayBuilder12AppendScalarERKNS_6ScalarEx`

Describe the bug, including details regarding any error messages, version, and platform.

I wanted to update arrow in Macports now, but linking of R-arrow 14.0.0 (what CRAN has released) fails for me against arrow 14.0.1:

/opt/local/bin/g++-mp-13 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/opt/local/Library/Frameworks/R.framework/Resources/lib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/local/lib/libgcc -L/opt/local/lib -lMacportsLegacySupport -arch ppc -o arrow.so RTasks.o altrep.o array.o array_to_vector.o arraydata.o arrowExports.o bridge.o buffer.o chunkedarray.o compression.o compute-exec.o compute.o config.o csv.o dataset.o datatype.o expression.o extension-impl.o feather.o field.o filesystem.o io.o json.o memorypool.o message.o parquet.o r_to_arrow.o recordbatch.o recordbatchreader.o recordbatchwriter.o safe-call-into-r-impl.o scalar.o schema.o symbols.o table.o threadpool.o type_infer.o -F/opt/local/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
installing to /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_R_R-arrow/R-arrow/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.3/Resources/library/00LOCK-arrow/00new/arrow/libs
** R
** inst
** tests
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘arrow’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_R_R-arrow/R-arrow/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.3/Resources/library/00LOCK-arrow/00new/arrow/libs/arrow.so':
  dlopen(/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_R_R-arrow/R-arrow/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.3/Resources/library/00LOCK-arrow/00new/arrow/libs/arrow.so, 6): Symbol not found: __ZN5arrow12ArrayBuilder12AppendScalarERKNS_6ScalarEx
  Referenced from: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_R_R-arrow/R-arrow/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.3/Resources/library/00LOCK-arrow/00new/arrow/libs/arrow.so
  Expected in: dynamic lookup

Error: loading failed
Execution halted
ERROR: loading failed

Is this something known?

R 4.3.2, gcc 13.2.0, arrow 14.0.1, macOS 10.6 / ppc (yeah, a good old one), Macports build env (no patches from our side applied to either arrow or R-arrow).

Component(s)

R

About this issue

  • Original URL
  • State: closed
  • Created 7 months ago
  • Comments: 21 (21 by maintainers)

Most upvoted comments

Hm, thanks for testing, not sure what the issue is but I’ll look into it

I have opened https://github.com/apache/arrow/issues/38776, https://github.com/apache/arrow/issues/38777 and https://github.com/apache/arrow/issues/38778 to adress the actual issues and will close this for now as your problem is solved for now. Please feel free to add any further comments in this issue even if it’s closed 😃

Just to summarize the issue, there are two actual issues here causing the titular build error of this issue:

  1. We download a cmake binary for the new bundled source build, for some reason this failed. (maybe because its ppc?)
  2. This error should have stopped the configure script and thus cancled the package install, it did not.
  3. (matching of versions might be to strict which caused the hotfixed macports 14.0.1 to be rejected)

In regards to your build setup and how to influence what libarrow isued / build:

  • By default arrow uses pkg-config to look for an existing install of arrow, which did happen here to but was rejected due to the version mismatch (see 3.)
  • ARROW_HOME can be set to an existing libarrow build (usually used in a dev context) and force that to be used, this will not be version checked, so you should be able to use that to force the use of your existing libarrow version. (or of course keep your workaround trhat patches out the version check)
  • LIBARROW_BINARY can be used to force a build from source with false or enable the use of precompiled binaries (default on macos but disabled on some linux distros) with true but only comes into play after pc and ARROW_HOME
  • LIBARROW_BUILD=FALSE can be used to explicitly disable source builds

I think LIBARROW_BINARY=false or LIBARROW_DOWNLOAD=false should prevent the source build (apologies if you already tried that!)

Just to be clear, you gonna retain an option to link to an external arrow in 15.0.0, right? That is desirable to have, at least as a non-default choice.

Yes the workaround is just due to the abseil version bump being painful in our bundled build (we use external project currently but can now use fetchcontent which will make version upgrades much easier).

Let me know if using arrow cpp 14.0.0 works to skip the bundled build 😃

We are also able to use a version of arrow cpp installed on the host found via pkg-config, which as you added it tp the port file will be build from source for macports should satisfy your policy?

You can enforce a source build with LIBARROW_BINARY=false. Set CMAKE to the path of cmake (>= 3.16) to skip the part where we download a cmake binary as that seems to be broken…

Ah it seems to be some issue with the cmake binary that we download, I will look into that. But that’s a downstream issue of this :info:destroot **** Not using: C++ library version (14.0.1) does not match R package (14.0.0) (and additionally it doesn’t kill the pkgbuild after the failed source build…? another thing to check ^^)

14.0.0 and 14.0.1 are identical for arrow cpp (it was a hotfix release for a python only cve). So just using arrow 14.0.0 will likely already skip the build from source 😃

I am unfamiliar with the macports build setup but with 14.0.0 we have completely overhauled the build system for the R package under macos and windows. That is likely the source for the issue as the build on macos now uses the same system as the linux build with pre-compiled binaries or build from source if that wasn’t found.

You could try to set LIBARROW_BINARY=true to force the use of the precompiled binaries (we have them for openssl 1.1 and 3) to skip the use of system arrow.

Do you have a CI run where I can see the complete log (specifically the bits at the beginning before the actual compilation)?

Sidenote are you cross compiling with quemu for 10.6 or how are you running such an old version?