lsp-dsp-lib icon indicating copy to clipboard operation
lsp-dsp-lib copied to clipboard

cannot build on Mac M2 using xcode toolchain

Open alex-tee opened this issue 1 year ago • 18 comments

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):

image

System info:

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

alex-tee avatar Sep 19 '24 06:09 alex-tee

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.

sadko4u avatar Sep 19 '24 08:09 sadko4u

uname -m says arm64

alex-tee avatar Sep 19 '24 08:09 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)

alex-tee avatar Sep 19 '24 08:09 alex-tee

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

sadko4u avatar Sep 19 '24 09:09 sadko4u

They both say Darwin

alex-tee avatar Sep 19 '24 09:09 alex-tee

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

sadko4u avatar Sep 19 '24 09:09 sadko4u

Thanks!

alex-tee avatar Sep 19 '24 09:09 alex-tee

I did some changes. Please try them. https://github.com/lsp-plugins/lsp-dsp-lib/commit/3132772c1d714130bd9a06db6a16aaedfc2cfffe

sadko4u avatar Sep 19 '24 19:09 sadko4u

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

image

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

image

Make version info:

image

(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)

alex-tee avatar Sep 20 '24 08:09 alex-tee

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.

sadko4u avatar Sep 20 '24 09:09 sadko4u

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

image

alex-tee avatar Sep 20 '24 09:09 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

image

and then it fails at linking:

image

alex-tee avatar Sep 20 '24 10:09 alex-tee

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.

sadko4u avatar Sep 20 '24 10:09 sadko4u

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):

image

alex-tee avatar Sep 20 '24 10:09 alex-tee

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

sadko4u avatar Sep 20 '24 10:09 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.

sadko4u avatar Sep 20 '24 11:09 sadko4u

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

The .o file seems to be the correct architecture:

image

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

And the implementation: https://github.com/jfalcou/eve/commit/eef36ada34634f929a04172c5ca6b01fd7bd6a62

alex-tee avatar Sep 20 '24 12:09 alex-tee

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?

sadko4u avatar Sep 20 '24 12:09 sadko4u

Got lsp-dsp-lib built on MacBook M1:

Overall unit test statistics:
  execution time [s]:   0.49
  launched:             135
  ignored:              0
  succeeded:            135
  failed:               0

macbook-m1:lsp-dsp-lib sadko$ uname -a
Darwin macbook-m1.local 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:34 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8103 arm64

The main problem with linker was, the linker for MacOS was required to pass the -keep_private_externs option to not to loss symbols marked as -fvisibility=hidden.

sadko4u avatar Nov 30 '24 20:11 sadko4u

Fixed in 1.0.28 release.

sadko4u avatar Dec 21 '24 02:12 sadko4u