-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clang18 linker error: 'libc++.so.1: no such file or directory' #70
Comments
Thanks for the detailed report! Nothing has changed in this image for a while, so this may be a change in clang 18 or in R-devel. I suggest we leave it alone for (say) a week, maybe it is transient and they'll fix it. If it is still happening in a week please ping me here and I'll take a closer look. |
Btw. all older containers are available at https://github.com/r-hub/containers/pkgs/container/containers%2Fclang18/versions Can you please double check that the one (say) a week ago works with the current version of your package and/or your reprex? Thanks. AFAICT there were no recent changes in R that could cause this. It also seems that there were no clang 18 changes, either. |
Thanks for that! I didn't know it was possible to see the old versions there, that's great. I tried each of those with my reproducible example, found that this one from 3 days ago is the first one that exhibits this problematic behavior:
I see the same issue in the image from 2 days ago.
BUT... it appears to already be fixed in the latest image 🎉
I tried writing out the environment and output of how I did that (click me)docker run \
--rm \
--platform linux/amd64 \
-it ghcr.io/r-hub/containers/clang18@sha256:75a7fed7bb116e1ba54cde6f6077d76731868a563ff3385d28264b2226336bbd \
R CMD config --all \
> ./broken.txt
docker run \
--rm \
--platform linux/amd64 \
-it ghcr.io/r-hub/containers/clang18@sha256:75a7fed7bb116e1ba54cde6f6077d76731868a563ff3385d28264b2226336bbd \
env \
>> ./broken.txt
docker run \
--rm \
--platform linux/amd64 \
-it ghcr.io/r-hub/containers/clang18@sha256:d3ab5ddce85e4d30e5e72a1974ab305ec42c1a51fdd10c724fb7dee61d67bae6 \
R CMD config --all \
> ./latest.txt
docker run \
--rm \
--platform linux/amd64 \
-it ghcr.io/r-hub/containers/clang18@sha256:d3ab5ddce85e4d30e5e72a1974ab305ec42c1a51fdd10c724fb7dee61d67bae6 \
env \
>> ./latest.txt There were 0 differences, so I guess it must have been something else. Since this appears to be working, I'm not planning to investigate it further... hopefully it was just something temporary we won't see again. Thanks very much for the help, and again... thanks for maintaining these images! They've allowed us to significantly improve the test coverage of the |
Thanks for these great images! They've been really helpful in replicating some of the harder-to-replicate CRAN checks.
I believe there's a configuration issue in the
clang18
image, although I'm not sure where precisely it is.Given a small C++ program like this...
... compiled like this ...
... the produced executable does not have linking information for
libc++.so.1
, and so fails like this when run:./conftest: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory
I found that there's only 1 copy of
libc++.so.1
in the image, at/usr/lib/llvm-18/lib
.Adding that to
LD_LIBRARY_PATH
allows loading to succeed.LD_LIBRARY_PATH=/usr/lib/llvm-18/lib \ ./conftest # this ran successfully
I did not expect to have to configure anything to compile a C++ program with
clang-18
in theclang18
image.Reproducible Example
Created a test script,
test.sh
.test.sh (click me)
Ran that with each of the
clang{nn}
images, like this:docker run \ --rm \ -v $(pwd):/opt/work \ -w /opt/work \ --platform linux/amd64 \ -it ghcr.io/r-hub/containers/clang18:latest \ ./test.sh
It succeeded on
clang16
,clang17
, andclang19
... but notclang18
.full logs from clang17 run (click me)
full logs from clang18 run (click me)
Notes
I did look in the output of
R CMD config --all
and tried to compare it to the details of theclang{nn}
checks described at https://cran.r-project.org/web/checks/check_issue_kinds.html. I don't see any obvious issues.I just started seeing this around 3-5 days ago... before that, similar code ran without issue in the
clang18
image produced here.For context, this pattern of gathering C++17 flags has been used in the
{lightgbm}
'sconfigure
script on CRAN for 2+ years, and attempts to follow the advice in https://cran.r-project.org/doc/manuals/R-exts.html#Using-C_002b_002b-code.The text was updated successfully, but these errors were encountered: