[R-pkg-devel] Question about Clang 17 Error
Martin Maechler
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Thu Oct 12 09:35:11 CEST 2023
>>>>> Reed A Cartwright
>>>>> on Wed, 11 Oct 2023 22:25:35 -0700 writes:
> Okay, I'll reach out to the CRAN team shortly.
> I wanted to run it by the group here first because my interactions with the
> CRAN team haven't always been positive and I need to make sure that I'm not
> missing something "obvious".
well.. one thing not enough obvious: Simon Urbanek _is_
part of the CRAN team (*). So at least you had a positive
interaction with "them", now ! ;-)
---
*) https://cran.r-project.org/CRAN_team.htm
(which is the *first* hit when I web search "CRAN team" {with
DuckDuckGo, a reasonable non-prying Google-alternative I})
Best,
Martin
> On Wed, Oct 11, 2023, 22:22 Simon Urbanek <simon.urbanek using r-project.org>
> wrote:
>> 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://urldefense.com/v3/__https://www.r-project.org/nosvn/R.check/r-oldrel-macos-x86_64/rbedrock-00install.html__;!!IKRxdwAv5BmarQ!bn6F_bNAOxSfAFbevyOMVGtmTQT-u-wuccyvwupscx__4Spd0Z8C0FoUWbCPQ8QfDC_9g64_bzdKRZTTqo2U99WvIfoR$>
>>
>> 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>
>> 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> 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$
>>>> 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>
>>>> 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>
>>>> > 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$
>>>> >> 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$
>>>> >>
>>>> >> Gabor
>>>> >>
>>>> >> On Wed, Sep 27, 2023 at 8:29 PM Reed A. Cartwright
>>>> >> <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$
>>>> >>>
>>>> >>> 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$
>>>> >>>
>>>> >>> [[alternative HTML version deleted]]
>>>> >>>
>>>> >>> ______________________________________________
>>>> >>> 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$
>>>> >>
>>>> > ______________________________________________
>>>> > 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$
>>>> >
>>>>
>>>>
>>
> [[alternative HTML version deleted]]
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
More information about the R-package-devel
mailing list