Skip to content

Added Dockerfile V1 #1694

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

davidcb98
Copy link

Good morning.

A few days ago I opened an issue due to a compilation problem in a cluster where I could not install the dependencies with apt-get.

Due to this problem I thought to make a docker container and compile inside the toolchain. I think it is interesting to add it to the repository and update it with the versions.

I think it would be interesting that when a new release of the toolchain is released, a container is left in DockerHub with the compiled toolchain.

To test it I compiled it with the options:

./configure --prefix=/opt/riscv --with-arch=rv64gc --with-abi=lp64d

Since different architectures and ABIs are supported, maybe an option to make the container more generic is to compile for several architectures and ABIs using “--with-multilib-generator=”. (I didn't test this option, but I think that's what it refers to).

To build the image, just have docker installed and run in the directory where the Dockerfile is the command:

docker build -t riscv-gnu-toolchain:2025.01.20_rv64gc_lp64d .

where before the colon (riscv-gnu-toolchain) is the name of the image and after (2025.01.20_rv64gc_lp64d) is the tag of the image.

Once you have the image, you only have to lift the container with the command

docker run --name riscv-gnu-toolchain -id riscv-gnu-toolchain:2025.01.20_rv64gc_lp64d bash

and run:

docker exec riscv64-unknown-linux-gnu-gcc -v

To run in HPC environment (clusters), you have to convert the image to singularity.

I look forward to your comments,
David

@cmuellner
Copy link
Collaborator

Hi @davidcb98,

Thanks for the PR!
The PR raises three questions for me:

  • Do we want to keep a Dockerfile, when we are not adding that to the CI (it will bitrot, because nobody will bump the base image)
  • What's the added value of a Dockerfile over the build.yaml
  • Which configuration would the Dockerfile cover (base OS, libc, baremetal/linux, simulator)?

I don't think a Dockerfile is bad, but if we have one, we should probably consider deploying the container to a registry. I'm happy to support this use case if there is demand from the user-side for it.

@davidcb98
Copy link
Author

Good morning,

First of all, thank you for your reply.

I am not an expert in software development so there are some issues that escape me. For example, I am not clear how Github Actions works and what is the build.yaml.

Also, I don't quite understand the first question, and about the third one, in the Dockerfile you can see that the image I chose was an ubuntu, although there are lighter alternatives. It's a first approximation to encourage you to give the subject a try.

I can tell you about a problem that I think that having a set of Docker images published on DockerHub can solve. I am a system administrator on a supercomputer (HPC) dedicated to scientific computing at the University of Malaga. In this kind of infrastructures we try to install all the software in a self-contained way. That is to say, the system has pre-installed a series of libraries and any dependency that needs a software has to be installed manually (without using apt-get).

This creates quite a few problems when installing software, as you have to fight with dependencies. When an installation gets complicated, the best thing to do is to install a Singularity image (which is obtained from the Docker image, as Docker is not used in HPC).

This is why I think that having a repository on DockerHub can make life much easier for system administrators.

Thank you very much,
David

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants