Using clang++

Bluefin
1

Was anyone able to make clang++ work? I am on bluefin-dx, I installed llvm with brew but when compiling a simple file that includes something from the standard libraries like iostream, it is not able to find the file. While g++ from brew is working fine.

2

I use distrobox for specialty, custom tool chains.

For example, I have been compiling python 3.14 while it has been in alpha, beta phases.

I spin up a temporary distrobox container, enter the distrobox, compile and install it to ~/opt/cpython, and then tear down the container to release the HD space.

I was doing the same for the zig toolchain as well. I use a combination of distrobox and devcontainers for all my projects.

The cool thing about this approach is I can manage the versions of tools in one place - a Containerfile !

Here is the repo where I have the tools I wrote to customize these kinds of distroboxen.

oci-shared-images/fedora/Containerfile.fedora-python314 at 69576a3bc061c2596a665d7fbba1e22baaebe8b4 · klmcwhirter/oci-shared-images · GitHub - for cpython 3.14

oci-shared-images/fedora/Containerfile.fedora-zig at 69576a3bc061c2596a665d7fbba1e22baaebe8b4 · klmcwhirter/oci-shared-images · GitHub - for building zig 0.14.0

Just clang, not clang++ - but the approach works for any toolchain.

3

Nice, would this work even if the tool searches in other directories for files like clang does when compiling?
I also add that brew’s clang is able to compile if you add compilation flags to manually point it to the include and lib directories that brew’s g++ uses, so maybe there is a solution that can use brew’s clang that just needs a little configuring.

4

I guess you did not read the main README.md in the repo.

TL;DR …
(a) mount your $HOME dir in the container - happens in distrobox.ini;
(b) enter the container to use the tool chain;
(c) build artifacts to be stored/installed in your $HOME dir structure only

Because I have come to the conclusion that “container first” means …

  • everything outside of $HOME are off limits - avoid modification; avoid depending on it
  • distrobox / devcontainer / flatpak should be first tool reached for (container first)
  • simple apps / tools (not compilers usually) can easily be exported via distrobox.ini
  • …
  • brew install should be close to last resort - good for simple one off tools (like btop or xclip) - not complex toolchains.

Does that answer your question?

Bottom line - avoid using brew for compiler toolchains - it is not meant for that. Use a distrobox or devcontainer instead.

You will fight with it a lot less. And have more control over updates, versions, etc.

EDIT: I guess I should mention that I have this alias created to simplify using distroboxen. Entering any box is a simple matter of changing an env var.

alias box='DBX_CONTAINER_MANAGER=${DBX_CONTAINER_MANAGER} distrobox enter -a --env=HOSTNAME=${CURR_CONTAINER_NAME} ${CURR_CONTAINER_NAME} -- bash'


$ CURR_CONTAINER_NAME=fedora-python-dx box
...
                                                                  
[klmcw@fedora-python-dx:~/src/soft.lan/klmcw/django-projects/budget-tracker]└4 master(+19/-472)* ± 
#      ^^^^^^^^^^^^^^^^  HOSTNAME changed on enter so I can easily tell I am in a box
# PWD kept upon enter   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5

I got tired of typing distrobox enter blah, so created this:

❯ cat ~/.local/bin/db
#!/bin/bash

if [ "$#" -eq 1 ]; then
    distrobox enter "$1"
else
    distrobox "$@"
fi

It would be a simple matter to add your env var definition(s) to save you some typing.

6

I do have some scripts where I need to encapsulate behavior, but use aliases where I just need a facade around a relatively lengthy command line for which I cannot effectively use tab-completion.

Given the alias above, I typically just type box[ENTER]. But I added the env vars so I can easily configure different sessions - like using a custom container that holds a complex toolchain that I am going to be using perhaps for a few days.

BTW, @Disco, in the repo I shared I have a patch for distrobox-export 1.8.1.2 that I apply while building the images so that when apps or binaries are exported the value of DBX_CONTAINER_MANAGER is exported to the proxy script or .desktop file. That way you can use both docker and podman to host distroboxen and export from both.

I tend to use podman for my “system” containers (longer lifespan; where I need stability) and docker for development. By separating by use case like that, I am free to do a docker system prune -af at anytime to clean things up.

7

You can use Mise to compile/install python, zig, ollama, clang and other tools and compilers.

1 Like
8

That does not address my problem, but may help others.

My use case is the need for multiple dev environments with differing versions of complex tool chains to enable git bisect / back porting efforts. Distrobox / Devcontainers are perfect for my needs. Nothing else works as well.

Most people are not going to have that non-functional requirement though.

Thanks for chiming in! I hadn’t heard of mise.

9

With mise you can set tools version for folder and change it before. For instance, I can set python for 3.11:

❯ mise use python@3.11
❯ python --version
Python 3.11.9

And change before to 3.12:

❯ mise use python@3.12
❯ python --version
Python 3.12.9

And changing to other folder I’ll have the system’s python as default:

cd ..
❯ python --version
Python 3.13.5
10

My use case involves closely managing version for 30 or so packages. Python, compiler chains, library versions, zig, go versions etc. It all depends on the project.

With containers it is all automated. I simply create the 5 or so containers before I start a git bisect session (with ocisictl process --prune) and use the correct one depending on which phase of the bisect I need to test.

But like I said, most devs do not have the requirements that I do.

Thanks again for sharing.

11

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.