cannot build on Mac M2 using xcode toolchain

[alex-tee]

I downloaded the latest release tarball, then I did:

make config PREFIX=/opt/lsp-dsp-lib

Then

make PREFIX=/opt/lsp-dsp-lib

and i got the following error (sorry for the screenshot, I can't copy paste from this VM):

System info:

• Mac mini 2023
• Apple M2 chip
• Sonoma 14.4
• Clang version arm64-apple-darwin23.4.0

[sadko4u]

Hello! What does uname -m say?
It seems like linker does not like some options and they should be omitted for Mac at the configuration stage make config.

[alex-tee]

uname -m says arm64

[alex-tee]

Also the library suffix doesn't seem to be detected properly for mac. It says it's trying to build an .so library but it should be .dylib (if building a shared library which is the default)

[sadko4u]

And what do the uname -s and uname -o say?

[alex-tee]

They both say Darwin

[sadko4u]

OK, I'll add some patches to the build system a bit later.

[alex-tee]

Thanks!

[sadko4u]

I did some changes. Please try them.
3132772

[alex-tee]

I'm getting some weird error after making those changes to the released tarball, some string is empty:

When trying from the devel branch directly, I can't fetch the dependencies:

Make version info:

(kinda off-topic, but is there a reason for using custom makefiles instead of something like cmake? It seems like it would be much easier to support various platforms by just using a build system generator)

[sadko4u]

Oh, LSP Plugins require GNU Make 4.1 and later. It seems that GNU Make 3.81 is one of the problems.
I think, even with CMake there could be problems of compiling for MacOS.

[alex-tee]

Ah I see! I installed gmake from homebrew, which is a newer version and now I can proceed to compile the git branch. It seems that the c++ standard is not specified in the compilation flags? Probably missing a --std=c++11 somewhere

[alex-tee]

I specified the c++std manually using CXXFLAGS when running gmake config and fixed that.

In lsp-common-lib/include/lsp-plug.in/stdlib/locale.h, it needs a:

#ifdef __APPLE__
#include "xlocale.h"
#endif
#include "locale.h"
...

and also the change below

and then it fails at linking:

[sadko4u]

It seems that the c++ standard is not specified in the compilation flags?

We assume that modern GCC and Clang automatically set up standard to at least C++11, so actually we don't need to specify it. We used to explicitly define --std=c++98 previously.

About patches: I'll apply them soon.

About linkage error: please launch make VERBOSE=1 to see the command line.

[alex-tee]

GCC and Clang automatically set up standard to at least C++11

I see, well Apple's clang doesn't seem to do that (on my machine at least). Doesn't hurt to add it explicitly I think.

Here's the full linker command (at the end). I show the compilation commands too in case they show something useful):

[sadko4u]

It may be the problem that *.o files are now compiled for the wrong target architecture.

[sadko4u]

I've pushed several changes to devel branches, try to re-fetch changes and build withiout specifying CXXFLAGS option.

Also, that is very sad that features.h should be modified in such way. That means that we have no proper way to detect support of ARM ASIMD/NEON for the CPU.

[alex-tee]

It builds without CXXFLAGS now, but still fails at linking with the same error.

The .o file seems to be the correct architecture:

From what I read online, Apple has its own specific way to detect ARM at runtime. See this for info:
jfalcou/eve#1478

And the implementation: jfalcou/eve@eef36ad

[sadko4u]

It looks like several *.o files have invalid/incompatible format. Maybe ld -r produces incompatible *.o file and needs some tuning.
Is it possible for you to determine the format of lsp-dsp-lib.o and any other regular *.o file produced by clang?