From the beginning of current year I am learning Docker. First result of this interest on my Github was publishing ccfactory tool, which was supposed to provide easy way to produce compiler toolchains. Almost like they were mass-produced in a factory, thus the name. However, since then I learned a lot and gained some experience. At the moment it is obvious to me, what I did then is not the best design. And because the project is still very fresh, I decided to start once again, from scratch, to create way better design that will be easy to develop and maintain.
Today is time to publish first step to this new design – binutils. I would not do that, but Docker Hub allows to have only one private repo, so the way that I do it disallows me to have it private anyway. So better idea is to describe it somehow to avoid confusion. As I wrote, this first step is binutils and this is simple container that contains binutils and nothing else. My goal is to finally make toolchain base on gcc version 3.3, which might sound weird, but this is what I needed in the past and is best way to prove what this new approach can achieve. With previous one, that I will call legacy from now on, I failed in that and before failing I did even more complicated Dockerfile, than originally planned. So, when finished this one will be proof of good design, I hope. Continue reading “New ccfactory on its way, binutils are already here”
Lately I play a bit with Docker containers. In a chain of problems that I have right now, I needed to have static cURL library on Debian. As it turned out linking cURL statically is not an easy task. Rather it causes a lot of problems, especially when trying this with packages available in Debian repos. After a long fight with these I decided to prepare my own distribution of cURL. But instead of creating usual deb package, I did it all on Docker and as a result, I have Docker image. In it I utilized possibilities of staged builds, where there can be few steps having in common only certain files. As a result I created base image, means the one created from scratch, where there are no other files, than the ones that we provide. So I provided only complete cURL install directory and musl libc to be able to run curl binary, as I did not want to tinker with cURL’s build system even more, than I did. Final image weights only ~1,5 MiB, so a result is really nice space saving compared to usual approach to Docker images. Inside, you can run curl binary separated from your operating system (to extent that Docker provides – remember, it is not virtualization!). Also it is possible to use libcurl to link your own binaries with it, this time completely statically!
As always, sources are on Github and this time there are also ready-to-use images on Docker Hub, so you can pull them directly, without need to build them. All instructions are on both pages and this is nothing unusual for any user of Docker, so I will not repeat myself here.
Few months ago I wrote a tutorial about creating Linux distribution consisting of just busybox as its userspace. In the meantime I worked a bit with docker and it sounded like nice next step in learning docker to automate the process of creating Linux distribution using it. As a result, today I present Linux distribution built with docker and based on my previous tutorial. I called it busy-linux due to it consisting of only busybox at the moment. My plan is to develop it further, most likely for private purposes only, so there might not be much happening in the project, but for sure I want to create dynamically linked variant in the near future, as this is what my use case requires. In the meantime feel free to try it yourself. Continue reading “Creating one-file Linux distribution with docker”
Having a tailored cross compiler is a problem I encountered couple of times in the past. Of course there are solutions to that problem like great crosstool-ng or more complex buildroot. In most cases crosstool-ng (ct-ng) can solve them. But whatever the tool we use, it has always its own drawbacks. For ct-ng these are small number of supported versions of toolchain components and huge dependence of environment, where it is started. The latter is even more problematic, because of the way continuing interrupted build work in ct-ng. Obviously if you want to build in example one compiler for ARM and one for MIPS, both consisting of latest tools, then it is not a problem.
But I have another use case for compiling toolchains. I do some reverse engineering from time to time. Nowadays many products have Linux under the hood and often there is no chance to get any SDK for them. But having ability to build something for the device can help a lot, either to run it there, or link with found tools and run in emulator. But I could also imagine that outside the reverse engineering field there might be a need to get toolchain in exact configuration, which is sadly not available via ct-ng or buildroot. Anyway, in any case where ct-ng or buildroot are not applicable, there is third way – docker. And this is the way I chose. This is how CC Factory appeared. It is docker container that builds gcc cross compiler on first startup and lands you in an container that have working compiler for the platform of your choice. And it does not require big effort to port it for the next architecture, or different tool version, unless the changes between the versions were really significant. Continue reading “Meet CC Factory – a factory for cross compilers”