search

Ericsson / CodeCompass

CodeCompass is a software comprehension tool for large scale software written in C/C++ and Java
https://codecompass.net
GNU General Public License v3.0
520 stars 102 forks source link

Dockerfiles to be modified for Apple Silicon #577

Closed baro77 closed 2 years ago

baro77 commented 2 years ago

Hi everybody, first of all thanks for CodeCompass... I was a SourceTrail (no more mantained) user and it hasn't been easy to find an alternative. Lucky to have landed here!

This issue just to share my experiece: I have a 14" MBP (Apple Silicon M1Pro) with macOS 12.3.1 and Docker Desktop 4.6.1 (76265)

Using provided Dockerfiles to build images as stated in the guide works, but when I tried to instantiate a container for codecompass:web via docker run I got this weird message:

[qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory]

where, of course, weirdness stems from the reference to x86_64 on an Apple Silicon. With docker image inspect I verified the images had all been created for arm64 platform, so my educated guess is that some x86_64 related stuff has been "hardcoded" in dockerfiles: I haven't understood what, but modifying all the FROM statements adding platform=linux/amd64 and rebuilding all the images solved the problem.

But of course it's sub-optimal to run x64 code on AppleSilicon: could you provide Dockerfiles fully honoring cpuarch? Thank you very much

whisperity commented 2 years ago

I'm not sure if anyone on the team has a macOS machine, let alone an M1 macOS machine... My educated guess would be that having generated an arm64 image instead of an amd64 image is the original mistake that had been made.

whisperity commented 2 years ago

When I search on DockerHub for CodeCompass, this is what I get. They are all tagged Linux and x86-64. Selecting ARM or ARM 64 in the filter on the left-hand side makes all results disappear.

image

And I cannot find any reference for arm64 in our source code. The latest build at https://hub.docker.com/layers/codecompass/modelcpp/codecompass/latest/images/sha256-82d3f07d2f240a652a354aca054078724a466e1a4abca3d74212987b1d9c1c0f?context=explore also shows

OS/ARCH linux/amd64

baro77 commented 2 years ago

Building for arm64 isn't a mistake tout-court: it can or cannot be done, given (or not) the support for arm64 of image dependencies and of the Dockerfile recipe (if image is built on x86-only lower images or dockerfile install executables or libraries only available in x86 flavor of course no hope to work natively on arm, but usually these kinds of problems can be solved); BTW, docker by default builds for local architecture, not preferentially for x86 (of course this behavior can be changed by platform statement)

Maybe you are right no developer has an Apple Silicon, that could explain why we only have x86-64 builds on DockerHub: however, given that they have kindly provided the dockerfiles to build all the stuff by ourselves without relying on DH, I tried to build natively for Apple Silicon... well to be honest I didn't try, docker did it by itself cause -as I said before- its default and expected choice is local architecture: that's why I have tried to ask if it's possible to have a build-workflow working for both architectures.

I hope any dev can tell me if it would be possible (in the case I'll wait patiently and grateful) or not (in that case I would anyway learn something new to me)

whisperity commented 2 years ago

given that they have kindly provided the dockerfiles to build all the stuff by ourselves without relying on DH, I tried to build natively for Apple Silicon...

@baro77 Oh, right, sorry! I misunderstood and thought the builds on DH are problematic. Now I understand you tried to build it yourself.

We, as in the team, do not have Apple devices, so we cannot test on a live and real system whether a build for ARM64 or M1 would be successful and working. So we cannot help in this regard. However, the code is free software, so you are welcome to try, and if you succeed, send the patch back. Once we understand the differences we MIGHT be able to unofficially keep it in sync with the incoming changes.

qemu-x86_64 I think this is related to your installation of Docker Desktop (which is not the same as the Docker kernel layer that is used on Linux) somehow. CodeCompass does not depend on or run anything related to qemu. All the steps that create the docker images are uploaded here into the repo. It's downloading an Ubuntu image and installing tools into it. CodeCompass does compile with (official, not Apple's own) Clang, so it might be possible that if you create a Dockerfile that uses a Mac-based image and Homebrew, it will work. There are two crucial external dependencies (as indicated in the documentation), Apache Thrift and CodeSynthesis ODB, both of which seem to been tried at some point in time on Macs:

Or do you not want to use a Mac-based image, but keep using Ubuntu in Docker, just for ARM64? Please advice what we should do? Is there a way to parametrise Dockerfiles from the outside so the platform= variable gets replaced in the FROM statement?

I am a bit confused as to what your wishes are.

whisperity commented 2 years ago

I think what is causing the loader problem are these lines:

ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini

Apparently, tini has other architecture releases such as tini-arm64 so I would try looking at changing the lines there and downloading the other binary and installing it as /tini should make the startup issue of the image go away.

baro77 commented 2 years ago

Next days I'll try looking at tini as you suggested, thanks. In the meanwhile, to clarify once more: I would like to build using dockerfiles and getting everything up&running natively on Apple Silicon (so everything compiled for arm). This is the standard behavior of docker: e.g. a FROM ubuntu:20.04 on a windows or linux machine by default pull x864-64 ubuntu image, on Apple Silicon the arm one is pulled. So, excluding the base images, it should something other done by dockerfiles (maybe installing tini for x86 regardless of current architecture, as you suggested). BTW Docker on Mac works by using an Alpine Linux arm VM where containers are run, and x86 code is executed in emulation if needed. I guess that qemu-64_x86 is the VM executing the x86 coded wrongly included in arm build-flow, and causing problem because of the x86-related missing file. As I said I'll try to follow your suggestion next days and I'll keep you up to date about (/maybe PRing) what I'll discover.

baro77 commented 2 years ago

Hi again! You were right! Tini was the guilty one, so I have just open PR#578 to modify Dockerfiles accordingly: I have removed the "manual" ADD and managed tini installation via apt as other packages... so the version for the local architecture is automatically chosen ('cause an arm ubuntu uses arm apt repository and x86 ubuntu the x86 apt packages): I think it's a more elegant solution than having to choose version based on naming in tini's original repo. All images build natively for arm64 on Apple Silicon and container run without previous halting error.

I still have problems because opening codecompass:web interface on http port 8010 I get a white empty page: but checking page source I can verify it's codecompass producing it, and I have the same problem trying amd64 version from DockerHub, so I guess I haven't still understood how to pass/process my source tree to be inspected by codecompass: so I guess this issue can be considered closed (maybe I'll hope another one if I'll not solve my current problem9

whisperity commented 2 years ago

Hey! Thanks. We'll close once the PR is reviewed, it's fine that way.

With regards to the code analysis, the documentation in the docker directory should give some pointers. You need to parse your project into a database which the Web interface will let you navigate.