bloomberg / blazingmq

A modern high-performance open source message queuing system
https://bloomberg.github.io/blazingmq/
Apache License 2.0
2.53k stars 130 forks source link

build_bde failing #123

Closed banipreetr closed 6 months ago

banipreetr commented 11 months ago

Is there an existing issue for this?

Current Behavior

On running: $ docker compose -f docker/single-node/docker-compose.yaml up --build -d

Getting the following error:

5.847 + bbs_build configure
5.847 /workspace/srcs/bde /workspace
5.873 qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory
5.873 Error: Command '['cmake', '/workspace/srcs/bde', '-G', 'Ninja', '-DCMAKE_BUILD_TYPE=Release', '-DBDE_BUILD_TARGET_64=1', '-DBDE_BUILD_TARGET_CPP17=1', '-DBdeBuildSystem_DIR:PATH=/workspace/srcs/bde-tools/BdeBuildSystem', '-DCMAKE_EXPORT_COMPILE_COMMANDS=ON', '-DBBS_BUILD_SYSTEM=ON', '-DBBS_USE_WAFSTYLEOUT=OFF', '-DBBS_CPP11_VERIFY_NO_CHANGE=OFF', '-DCMAKE_INSTALL_PREFIX=/opt/bb', '-DCMAKE_INSTALL_LIBDIR=lib64', '-DCMAKE_TOOLCHAIN_FILE=/workspace/srcs/bde-tools/BdeBuildSystem/toolchains/linux/gcc-default.cmake', '-DCMAKE_PREFIX_PATH:PATH=///opt/bb', '--log-level=ERROR']' returned non-zero exit status 255.
5.873 Configuration cmd:
5.873 cmake /workspace/srcs/bde -G Ninja -DCMAKE_BUILD_TYPE=Release -DBDE_BUILD_TARGET_64=1 -DBDE_BUILD_TARGET_CPP17=1 -DBdeBuildSystem_DIR:PATH=/workspace/srcs/bde-tools/BdeBuildSystem -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DBBS_BUILD_SYSTEM=ON -DBBS_USE_WAFSTYLEOUT=OFF -DBBS_CPP11_VERIFY_NO_CHANGE=OFF -DCMAKE_INSTALL_PREFIX=/opt/bb -DCMAKE_INSTALL_LIBDIR=lib64 -DCMAKE_TOOLCHAIN_FILE=/workspace/srcs/bde-tools/BdeBuildSystem/toolchains/linux/gcc-default.cmake -DCMAKE_PREFIX_PATH:PATH=///opt/bb --log-level=ERROR
------
failed to solve: process "/bin/sh -c bin/build_deps.sh" did not complete successfully: exit code: 1

Laptop spec: Docker Version: 24.0.6 Macbook M2 Air

Expected Behavior

Build to complete without any issues

Steps To Reproduce

  1. Clone the repository
  2. Follow the first step here: https://bloomberg.github.io/blazingmq/docs/getting_started/blazingmq_in_action/ 3

BlazingMQ Version

1.13.3

Anything else?

N/A

banipreetr commented 11 months ago

This solution worked for me: https://stackoverflow.com/questions/71040681/qemu-x86-64-could-not-open-lib64-ld-linux-x86-64-so-2-no-such-file-or-direc however

Cartroo commented 11 months ago

To make things more concrete, I had some issues with some ways of setting the platform both in Dockerfile and using environment variables. In the end, the only way that worked for me was making this change in the docker-compose.yaml file:

diff --git a/docker/single-node/docker-compose.yaml b/docker/single-node/docker-compose.yaml
index 5039bdb..c7ba220 100644
--- a/docker/single-node/docker-compose.yaml
+++ b/docker/single-node/docker-compose.yaml
@@ -1,5 +1,6 @@
 services:
   bmqbrkr:
+    platform: linux/amd64
     image: bmqbrkr:latest
     build:
       context: ../..
@@ -10,6 +11,7 @@ services:
     command: "/usr/local/bin/bmqbrkr /etc/local/bmq"

   bmqtool:
+    platform: linux/amd64
     image: bmqbrkr:latest
     build:
       context: ../..

Some of the issues may have been due to caching, though, so I found it useful to totally remove any chance of caching with docker system prune --all --force, although be aware this will clean up a lot of things across all your containers. There are less drastic approaches that will probably work, but I didn't want to mess with it.

pniedzielski commented 11 months ago

Hi @banipreetr and @Cartroo,

For developing on an M1/M2 Mac, we have been using the build-darwin.sh script, or vcpkg. I'd like to make sure, in case there's a bigger issue, does that script work for you?

If it does, it sounds like a Docker related issue, and one we had run into (and you'll probably run into using Docker on Apple silicon quite often). @Cartroo, it sounds like the instructions here didn't work for you? I'm going to double check with a fresh cache on an M2 Mac, but it may be worth adding your suggested changes anyway, just to be safe. Additionally, I'll update our docs to mention the solution in Issue #45.

Thanks!

Cartroo commented 11 months ago

@Cartroo, it sounds like the instructions here didn't work for you?

Setting DOCKER_DEFAULT_PLATFORM=linux/amd64 didn't seem to work for me earlier, no. However, I can't entirely promise that it wasn't some odd issue with cached images etc. — you know what it's like when you're trying to get something working, it's easy to forget to do clean builds. I'd had some earlier problems with an incorrectly set DNS server in my Docker configuration, which confused things at first.

I'm trying again now with that, having cleaned out all the Docker caches, so perhaps with a clean build it will work. I certainly can't think of a legitimate reason why setting it in docker-compose.yaml would be different from setting DOCKER_DEFAULT_PLATFORM (though I freely admit I'm no Docker expert).

Cartroo commented 11 months ago

I can confirm that a local build with bin/build-darwin.sh worked, once I'd done brew install cmake and ninja. There were a huge number of warnings when building BDE, many of which were about -Wlogical-op which I don't believe clang supports — there were also warnings of missing switch cases, unused variables, missing newlines on autogenerated files, etc. I'm assuming that these are probably expected, however, and they don't appear to have prevented working binaries being produced (although I haven't used them for much yet!).

kaikulimu commented 11 months ago

@Cartroo I am glad to hear that the bin/build-darwin.sh script worked smoothly. The warnings from our dependency BDE libraries are sub-optimal, but I don't think they have any negative effects on the output binaries. A large number of them stem from customized C++ usages which slightly deviate from standard C++ best practices.

kaikulimu commented 11 months ago

Some warnings are also being actively addressed in PRs such as #125.

pniedzielski commented 6 months ago

Please re-open this if it is needed. We haven't been able to reproduce this issue on M1/M2 Macs, and it looks there are known workarounds.