[R-pkg-devel] Question about Clang 17 Error

Thu Oct 12 07:22:04 CEST 2023

Reed,

please contact CRAN - this list can only help with general developer's questions, not specific issues with a particular CRAN setup - only the corresponding member of CRAN running the setup can help. I don't see anything obvious - we can see that it's a mismatch of run-times between the cmake build and the R linking, but from the package alone it's not clear to me why.

Cheers,
Simon

> On Oct 12, 2023, at 3:51 PM, Reed A. Cartwright <racartwright using gmail.com> wrote:
> 
> Update: I submitted a new version of the package, but it did not fix the issue. The package has now been archived and I do not have access to the error log output anymore from r-devel-linux-x86_64-fedora-clang.
> 
> I did reproduce CRAN's configuration in a VM using the information provided by CRAN for r-devel-linux-x86_64-fedora-clang. I still cannot reproduce the error and at this point I believe that there is a chance that CRAN's machine is misconfigured.
> 
> The specific error happens after rbedrock has been compiled and linked successfully. The specific error is that the symbol _ZNSt3__122__libcpp_verbose_abortEPKcz cannot be found when rbedrock.so is loaded.This symbol was introduced into libc++ in Clang 15.0. What I believe to be happening to cause the error is that Clang++ 17 is adding a reference to this symbol when compiling and linking rbedrock.so but the dynamic linker is loading an older version of libc++.so when trying to load rbedrock.so and the symbol is not found.
> 
> If this is the cause, then I think that the CRAN machine needs to configure the dynamic linker to use the Clang++ 17 libc++.so, or add the proper command line options to R's config variables.
> 
> It's possible that the CRAN's r-devel-linux-x86_64-fedora-clang machine is fine and I've missed something, and I would be happy if someone could help me figure out what it is.
> 
> Also, a new issue cropped up when 0.3.1 was tested on the r-oldrel-macos-x86_64 machine. /usr/bin/ar seems to have failed to produce an archive. The other Mac versions did fine, so I'm not sure if this is a random error or something related to my package. The error log is here: https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/rbedrock-00install.html <https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/rbedrock-00install.html>
> 
> If anyone can help me resolve this, I'd appreciate it.
> 
> 
> On Wed, Sep 27, 2023 at 2:54 PM Reed A. Cartwright <racartwright using gmail.com <mailto:racartwright using gmail.com>> wrote:
> Is there any way to submit packages directly to the CRAN's clang17 setup? I can enable verbose output for CMake and compare the output, but I'd rather not clog up the CRAN incoming queue just to debug a linker error?
> 
> On Wed, Sep 27, 2023 at 2:43 PM Simon Urbanek <simon.urbanek using r-project.org <mailto:simon.urbanek using r-project.org>> wrote:
> It looks like a C++ run-time mismatch between what cmake is using to build the static library and what is used by R. Unfortunately, cmake hides the actual compiler calls so it's hard to tell the difference, but that setup relies on the correct sequence of library paths.
> 
> The rhub manually forces -stdlib=libc++ to all its CXX flags
> https://urldefense.com/v3/__https://github.com/r-hub/rhub-linux-builders/blob/master/fedora-clang-devel/Makevars__;!!IKRxdwAv5BmarQ!bAZgiOQaK4hd5BTk_Ldx9IEHgzHKVbC-uMkvYv5GOVkZDvbedcGwS8dQ4MWXRjukFfds7UpiR9NDZfEoUCWeoVnCfrDa$ <https://urldefense.com/v3/__https://github.com/r-hub/rhub-linux-builders/blob/master/fedora-clang-devel/Makevars__;!!IKRxdwAv5BmarQ!bAZgiOQaK4hd5BTk_Ldx9IEHgzHKVbC-uMkvYv5GOVkZDvbedcGwS8dQ4MWXRjukFfds7UpiR9NDZfEoUCWeoVnCfrDa$> 
> so it is quite different from the gannet tests-clang-trunk setup (also note the different library paths), but that's not something you can do universally in the package, because it strongly depends on the toolchain setup.
> 
> Cheers,
> Simon
> 
> 
> > On 28/09/2023, at 9:37 AM, Reed A. Cartwright <racartwright using gmail.com <mailto:racartwright using gmail.com>> wrote:
> > 
> > I was unable to reproduce the error on the rhub's clang17 docker image.
> > 
> > I notice that the linking command is slightly different between systems.
> > And this suggests that I need to find some way to get CRAN to pass -stdlib
> > flag at the linking stage.
> > 
> > CRAN:
> > /usr/local/clang17/bin/clang++ -std=gnu++17 -shared
> > -L/usr/local/clang/lib64 -L/usr/local/clang17/lib -L/usr/local/gcc13/lib64
> > -L/usr/local/lib64 -o rbedrock.so actors.o bedrock_leveldb.o dummy.o init.o
> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
> > -pthread -lleveldb -lz
> > 
> > RHUB:
> > clang++-17 -stdlib=libc++ -std=gnu++14 -shared -L/opt/R/devel/lib/R/lib
> > -L/usr/local/lib -o rbedrock.so actors.o bedrock_leveldb.o dummy.o init.o
> > key_conv.o nbt.o random.o subchunk.o support.o -L./leveldb-mcpe/build
> > -pthread -lleveldb -lz -L/opt/R/devel/lib/R/lib -lR
> > 
> > On Wed, Sep 27, 2023 at 11:36 AM Gábor Csárdi <csardi.gabor using gmail.com <mailto:csardi.gabor using gmail.com>>
> > wrote:
> > 
> >> You might be able to reproduce it with the clang17 container here:
> >> 
> >> https://urldefense.com/v3/__https://r-hub.github.io/containers/__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoLqhhk9c$ <https://urldefense.com/v3/__https://r-hub.github.io/containers/__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoLqhhk9c$>
> >> You can either run it directly or with the rhub2 package:
> >> 
> >> https://urldefense.com/v3/__https://github.com/r-hub/rhub2*readme__;Iw!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoxPbUQlE$ <https://urldefense.com/v3/__https://github.com/r-hub/rhub2*readme__;Iw!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoxPbUQlE$>
> >> 
> >> Gabor
> >> 
> >> On Wed, Sep 27, 2023 at 8:29 PM Reed A. Cartwright
> >> <racartwright using gmail.com <mailto:racartwright using gmail.com>> wrote:
> >>> 
> >>> My package, RBedrock, is now throwing an error when compiled against
> >>> Clang17. The error log is here:
> >>> 
> >>> 
> >> https://urldefense.com/v3/__https://www.stats.ox.ac.uk/pub/bdr/clang17/rbedrock.log__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoNhThuZA$ <https://urldefense.com/v3/__https://www.stats.ox.ac.uk/pub/bdr/clang17/rbedrock.log__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FoNhThuZA$>
> >>> 
> >>> The important part is
> >>> """
> >>> Error: package or namespace load failed for ‘rbedrock’ in dyn.load(file,
> >>> DLLpath = DLLpath, ...):
> >>> unable to load shared object
> >>> 
> >> '/data/gannet/ripley/R/packages/tests-clang-trunk/rbedrock.Rcheck/00LOCK-rbedrock/00new/rbedrock/libs/rbedrock.so':
> >>> 
> >>> 
> >> /data/gannet/ripley/R/packages/tests-clang-trunk/rbedrock.Rcheck/00LOCK-rbedrock/00new/rbedrock/libs/rbedrock.so:
> >>> undefined symbol: _ZNSt3__122__libcpp_verbose_abortEPKcz
> >>> Error: loading failed
> >>> """
> >>> 
> >>> From what I can gather through googling, this error can be caused by
> >> using
> >>> the C linker when one of the dependent libraries is a C++ library.
> >>> 
> >>> I cannot tell if this is an issue with my package (likely) or CRAN's
> >>> clang17 setup (less likely).
> >>> 
> >>> Background about the package: rbedrock is written in C but links against
> >> a
> >>> C++ library (Mojang's leveldb fork)  via the library's C-API functions. I
> >>> use a dummy .cpp file in the source directory to trigger R into using the
> >>> C++ linker. That does still seem to be happening according to the log.
> >>> 
> >>> Has anyone seen this before and know where I should start looking to fix
> >> it?
> >>> 
> >>> Thanks.
> >>> 
> >>> --
> >>> Reed A. Cartwright, PhD
> >>> Associate Professor of Genomics, Evolution, and Bioinformatics
> >>> School of Life Sciences and The Biodesign Institute
> >>> Arizona State University
> >>> ==================
> >>> Address: The Biodesign Institute, PO Box 876401, Tempe, AZ 85287-6401 USA
> >>> Packages: The Biodesign Institute, 1001 S. McAllister Ave, Tempe, AZ
> >>> 85287-6401 USA
> >>> Office: Biodesign B-220C, 1-480-965-9949
> >>> Website:
> >> https://urldefense.com/v3/__http://cartwrig.ht/__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-Fo7waq1VI$ <https://urldefense.com/v3/__http://cartwrig.ht/__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-Fo7waq1VI$>
> >>> 
> >>>        [[alternative HTML version deleted]]
> >>> 
> >>> ______________________________________________
> >>> R-package-devel using r-project.org <mailto:R-package-devel using r-project.org> mailing list
> >>> 
> >> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FocAOfF7A$ <https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!a5vkX68B5unua6_Zsh92b99AXfbJiewU7Mp0nqAKE0JDT8v3g2d08JZ8Yq_0ubp0j4GeTWWLjLVAN-FocAOfF7A$>
> >> 
> > ______________________________________________
> > R-package-devel using r-project.org <mailto:R-package-devel using r-project.org> mailing list
> > https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!bAZgiOQaK4hd5BTk_Ldx9IEHgzHKVbC-uMkvYv5GOVkZDvbedcGwS8dQ4MWXRjukFfds7UpiR9NDZfEoUCWeoZEUmVSQ$ <https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!bAZgiOQaK4hd5BTk_Ldx9IEHgzHKVbC-uMkvYv5GOVkZDvbedcGwS8dQ4MWXRjukFfds7UpiR9NDZfEoUCWeoZEUmVSQ$> 
> > 
> 

	[[alternative HTML version deleted]]