Skip to content
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

Add a Dockerfile that supports buildx for amd64/arm64 #8

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

Conversation

TrueBrain
Copy link
Contributor

Not sure if you are interested in this, so feel absolutely free to close this PR.

I was trying to build arm64 Docker images via buildx, as I normally do. Sadly, because the Dockerfile has hardcoded references to x86_64, this failed.

So, I added some glue in the Dockerfile, allowing it to pick the right folders depending on the platform you are building for. I only added support for amd64 and arm64, as those are my target / and what I can test.
I put it in another Dockerfile, as the normal docker build doesn't understand this redirect via $TARGETARCH. They couldn't make this easy, ofc.

But, with that, buildx happily builds FlashMQ, and it even works on arm64 just fine :)

@halfgaar
Copy link
Owner

Thanks, I'll take a look. Contributions for Docker are certainly welcome. I spent a fair amount of time on getting packaging in order (not an easy task), but Docker I haven't done much on.

It'd be best if there was one Docker file, and depending how wide-spread buildx is (it's new to me), I may replace the original Dockerfile.

A little background on the architecture BTW: FlashMQ primarily targets x64 because it has SSE4.2 instructions for string handling, making it faster. There's a fallback for ARM builds, but it's good to be aware of somewhat reduced performance. ARM has various SSE/SIMD instructions, but not all.

@TrueBrain
Copy link
Contributor Author

TrueBrain commented Jul 23, 2022

A little background on the architecture BTW: FlashMQ primarily targets x64 because it has SSE4.2 instructions for string handling, making it faster. There's a fallback for ARM builds, but it's good to be aware of somewhat reduced performance. ARM has various SSE/SIMD instructions, but not all.

Tnx for that background info; explains why I had to disable see4.2 from the main CMake-file before I could build it for arm64 ;) Builds otherwise fine without that statement btw.
Maybe funny for you to know: mostly why I picked FlashMQ is because of the websocket implementation. The others I tried had very shitty implementation, that failed in weird ways when put behind an (SSL) proxy :)

@halfgaar
Copy link
Owner

That's very interesting to know. Also note that it supports websocket TLS natively (no need for proxy, unless you want to of course).

Websockets remain hard to test thoroughly, because of the lack of clients out there (it's mostly PAHO), and some are buggy themselves. HiveMQ's client incorrectly assumes websocket frames align with MQTT frames for instance, something that should not be assumed, as mentioned explicitly in the specs.

Should you run into weird behavior, I'd even do an interactive debugging session.

BTW, I hope you have the newest version, because of this.

@jyvern jyvern mentioned this pull request Feb 27, 2023
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