Messagepack misdetected

[koen219]

Hoi Lourens,

When trying to compile muscle3 on my Mac I get some errors. Per your request I included the details below.

Best, Koen

The logger: Checking for msgpack >= 3.1.0...

• msgpack_ROOT set to
• msgpack 4.0.0 found at /opt/homebrew/Cellar/msgpack/4.0.0

The error: data.hpp:10:10: fatal error: 'msgpack.hpp' file not found

My system: macOS Monterey v12.4 Apple M1 2020

[LourensVeen]

Some more information: msgpack was installed with brew, and the msgpack package only has the C bindings. There's a separate msgpack-cpp package for the C++ bindings, but it doesn't have pkgconfig files, so it's not detected. So the msgpack that was found above is the C version, and it gets found even if you also install the C++ one.

That seems a bit broken. Since macOS likes to package up each application in its own directory with all its dependencies, perhaps it's better to detect that we're on a Mac and in that case always build our own msgpack?

[LourensVeen]

It seems that the pkg-config situation was partially an upstream problem, where it has been fixed recently, as a result of which we don't seem to misdetect recent versions of msgpack-c as msgpack-cpp. Unfortunately, Homebrew still doesn't install PkgConfig files with the C++ package, so we cannot detect it and end up building our own. That takes a couple MB extra disk space but otherwise works, so we'll call that good enough.

[koen219]

Hi Lourens,

Today I tried again to compile muscle3 and stumbled into this issue again. For further reference to myself this is what I did to make it work:

Find the Makefile at libmuscle/cpp/build/Makefile and change the lines reading

dep_name := msgpack
dep_version_constraint := >= 3.1.0
dep_version := 3.2.0
dep_pkgconfig_name := msgpack
dep_install := 1
include $(TOOLDIR)/make_available.make

into

dep_name := msgpack
dep_version_constraint := >= 3.1.0
dep_version := 3.2.0
dep_pkgconfig_name := msgpack
dep_install := 1
# include $(TOOLDIR)/make_available.make
ifneq ($(MAKECMDGOALS),clean)
include $(TOOLDIR)/dep_build.make
endif

This build msg pack as was suggested above by Lourens.

[LourensVeen]

Oh joy. Are you still using Homebrew? Do you have msgpack installed via Homebrew?

The CI is building, but I'm not installing msgpack at all there and just let the M3 build system do it. So it seems that where before if you installed msgpack via Homebrew things were broken, but it didn't get detected and we built our own and everything was fine. It looks like something has changed and now it gets detected, but it's still broken so we crash. I'd need to see the exact build output to see what's going on.

I'll try and experiment a bit with the CI and see if I can reproduce this, meanwhile more information would be welcome.

[LourensVeen]

I've just tested this on the CI, and in both cases the Homebrew-installed msgpack does not get detected, after which MUSCLE3 builds and install msgpack itself and everything works. I've tested

MacOS Ventura 13.6.3
Xcode 14.3.1
Apple clang 14.0.3

msgpack-cxx 6.1.0 from Homebrew

and

MacOS Monterey 12.7.2
Xcode 14.2
Apple clang 14.0.0

msgpack 6.0.0 from Homebrew

Note that MUSCLE3 uses the C++ version, so we would expect it to not detect the C version, but that was problematic in the past so I wanted to test.

Could you post or send me your build output? Without that I'm not going to be able to figure out what's going on here.

[koen219]

I think you are right. When I clone and make muscle3, message pack gets detected. The problem lies in the specifics of the Tissueopt project and not with M3.

[LourensVeen]

It does get detected? So that's different from what the CI is doing then? Which msgpack do you have installed, and how was it installed?

[koen219]

Hi Lourens,

To be fair, I'm getting confused. When I compile muscle3 It finds msgpack to be detected at "/usr/local", it is installed via home-brew as a dependency for different software. It looks like it's using that one?

makeout.txt

Best,

Koen

[LourensVeen]

Yes, it's picking up msgpack from the brew install and then it uses it successfully. So at least if you're compiling MUSCLE3 separately it's working exactly as designed.

Let's continue this discussion in the TST repo and see if there's anything I've done there that messes things up. Also, since this confirms that this issue is fixed with the current releas, I'm going to close this finally. Yay :smile:.