silkeh / docker-clang Goto Github PK

The following recipe:

docker run --rm -it silkeh/clang:3.4
mkdir cmake_test
cd cmake_test
printf "cmake_minimum_required(VERSION 3.1)\n project(MyProject LANGUAGES CXX)" > CMakeLists.txt
cmake .

broke recently (probably about a month ago):

-- The CXX compiler identification is Clang 3.4.2
-- Check for working CXX compiler: /usr/local/bin/clang++
-- Check for working CXX compiler: /usr/local/bin/clang++ -- broken
CMake Error at /usr/share/cmake-3.13/Modules/CMakeTestCXXCompiler.cmake:45 (message):
  The C++ compiler

    "/usr/local/bin/clang++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /cmake_test/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/bin/make" "cmTC_f4363/fast"
    /usr/bin/make -f CMakeFiles/cmTC_f4363.dir/build.make CMakeFiles/cmTC_f4363.dir/build
    make[1]: Entering directory '/cmake_test/CMakeFiles/CMakeTmp'
    Building CXX object CMakeFiles/cmTC_f4363.dir/testCXXCompiler.cxx.o
    /usr/local/bin/clang++     -o CMakeFiles/cmTC_f4363.dir/testCXXCompiler.cxx.o -c /cmake_test/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
    Linking CXX executable cmTC_f4363
    /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_f4363.dir/link.txt --verbose=1
    /usr/local/bin/clang++       -rdynamic CMakeFiles/cmTC_f4363.dir/testCXXCompiler.cxx.o  -o cmTC_f4363
    /usr/bin/ld: cannot find crtbegin.o: No such file or directory
    /usr/bin/ld: cannot find -lstdc++
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[1]: *** [CMakeFiles/cmTC_f4363.dir/build.make:87: cmTC_f4363] Error 1
    make[1]: Leaving directory '/cmake_test/CMakeFiles/CMakeTmp'
    make: *** [Makefile:121: cmTC_f4363/fast] Error 2




  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "/cmake_test/CMakeFiles/CMakeOutput.log".
See also "/cmake_test/CMakeFiles/CMakeError.log".

(MWE, an actual example is CLI11's CI system). Also fails with 3.5, works with (larger?) 8. image.

Edit: Could it be that clang 3.x is not supported by libstdc++ 8? 16ae1f4

Edit: Shorter version for easier version checking:

docker run --rm silkeh/clang:3.4 /bin/bash -c 'mkdir cmake_test; cd cmake_test; printf "cmake_minimum_required(VERSION 3.1)\n project(MyProject LANGUAGES CXX)" > CMakeLists.txt; cmake .'

I was trying to compile a c++ program but compiler cannot find standard libraries

test.cc

#include <iostream>

int main() {
    std::cout << "Hello world" << std:endl;
}

output

test.cc:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.

I tried quickly adding support for LLVM 10, but they changed the download URL again so I couldn't get it to work in the existing script... Perhaps it's better to simply hardcode the URLs?

Hello,

Just discovered your image and it looks great !
I plan to use it as a base for some of mine and would like to use them on AppleSilicon macs, I saw in config.yaml that ARM is listed, but the docker hub images don't support it ?

Is it a bug, is it normal ?

I am not sure if this is an error, but the clang 11 image is missing from Docker Hub and latest is clang 10.

Thanks for the great project!

Compiling a program fails when enabling link-time optimisations (LTO). The problem can be reproduced by running the following command in the Docker image:

$ echo "int main(){}" >> main.cpp; clang++ main.cpp -flto=thin
/usr/bin/ld: /usr/local/bin/../lib/LLVMgold.so: error loading plugin: /usr/local/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory

I unfortunately have no idea what should be done to fix this issue.

First of all, thank you for maintaining these images, they are really helpful!

I was excited to see #12 had been merged with some nice updates. It looks like you've published them to docker-hub, however there doesn't seem to be a tag for clang 12.

If you are able to push that, it would be most appreciated!

Thanks again :)

Hey, it'd be great to add Clang 17 as Clang 17 is now available; https://github.com/llvm/llvm-project/releases/tag/llvmorg-17.0.3

There is only an image for Clang 14. The dev image is already at Clang 16 (16.0.0-++20220929071807+682c7c77f59a-1exp120220929071906.404), but there is no image for Clang 15.

The linker error:

/usr/bin/ld: CMakeFiles/environment.dir/environment.cpp.o: in function (anonymous namespace)::environment_t_constructor_Test::TestBody()':
environment.cpp:(.text+0xc6): undefined reference to std::filesystem::__cxx11::path::_M_split_cmpts()'

The code compiled on a local clang and a docker gcc.

The image is missing libc++.

Although it comes with libstdc++, which is a requirement of clang, I would expect a clang/llvm image to also include libc++.

You can simply install it with (as per https://apt.llvm.org/):

apt-get install libc++-{version}-dev libc++abi-{version}-dev

I think clang will still pick libstdc++ by default, unless otherwise specified (i.e. -stdlib=libc++), so I see no real argument against it. What do you think?

• Clang 14 has been out since March, would be nice to have a Docker image for it as well.

Would you add clang 16 as LLVM 16 was released last week?
https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.1

Wanted to continue the discussion from #28 (comment) in a dedicated issue.

So I've looked into how these new multi-arch images work.

The last time I did some work on this it seemed like the image needed to be pushed for all architectures at the same time.

This seems to be the recommended and easiest way to handle multi-arch images.

However, I found a way to build these images independently and stitch them together afterwards (see "The hard way with docker manifest" https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/). This would require us to upload each image for each architecture with its own tag to the registry, then creating a new "tag" or manifest which combines them. Afterwards the initial tags can be deleted, because their layers are referenced by the new manifest.

Interestingly, the docker manifest create command is marked experimental and not recommended for production. On the other hand, there's docker buildx imagetools create, which might work the same way.

This is the best I can come up with, yet. I don't like the fact, that we're required to push the "intermediate" images first, and I'm not sure if that's an acceptable solution. Furthermore it would increase the complexity of the task. What do you think?

I also couldn't find 1) how to improve the readability of the logs (only through --output=plain) nor 2) allow individual architectures to fail, while keeping the successfully build, as alternative solutions.

Use with cmake, clang++ tried to use libstdc++ in base, which was pre c++17.

Hi,

Thanks for publishing this useful Docker image, it really helped me a lot!

However, I find it a little annoying that the image published in Docker Hub under the tag 10 (silkeh/clang:10) actually has LLVM 9.0 installed in it, which can be found from the image history. The LLVM version under the tag latest is 10.0 btw.

It will be great if you can update this tag!

I have a couple of questions:

The container images are tagged with the major version of clang -- do you rebuild the image when there are patch (or minor) releases of clang?

Also, for example the image tagged with 17, that would be same as 17-bookworm (latest stable), right? Wonder by the digest is different.. https://hub.docker.com/r/silkeh/clang/tags?page=1&name=17

Thanks for this great work!

I like your work!

I came across a slight infelicity this morning. When you want to apt install extra packages, some might depend on a C compiler being around. libtool is one of them.

Under debian, libtool is marked as depending on the virtual package c-compiler, which can be provided by a variety of compilers. Presently, on bullseye this pulls gcc-10 by default.

The sad thing is that your images do have a compiler, of course, and this pull of gcc seems largely unneeded. Would you welcome a modification that creates a phony intermediate package that provides the c-compiler dependency (along with the required symlinks and alternatives set up) ?