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 <racartwri...@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 <racartwri...@gmail.com > <mailto:racartwri...@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.urba...@r-project.org > <mailto:simon.urba...@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 <racartwri...@gmail.com > > <mailto:racartwri...@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.ga...@gmail.com > > <mailto:csardi.ga...@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 > >> <racartwri...@gmail.com <mailto:racartwri...@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@r-project.org <mailto:R-package-devel@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@r-project.org <mailto:R-package-devel@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]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
