Build fails on macOS

[ubolonton]

Build fails on macOS 0.13.4 (17E199).
Package manager is MacPorts.

This is the error:

[100%] Linking C shared library libegit2.dylib
Undefined symbols for architecture x86_64:
  "_libiconv", referenced from:
      _git_path_iconv in libgit2.a(path.c.o)
  "_libiconv_close", referenced from:
      _git_path_iconv_clear in libgit2.a(path.c.o)
  "_libiconv_open", referenced from:
      _git_path_iconv_init_precompose in libgit2.a(path.c.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/libegit2.dylib] Error 1
make[1]: *** [src/CMakeFiles/egit2.dir/all] Error 2
make: *** [all] Error 2

[TheBB]

I'd be happy to receive build patches for other OSes. I don't have a Mac. :-/

[TheBB]

rust-lang/cargo#1032 seems relevant.

Can you check where your libiconv is, if cmake can find it correctly and if it invokes linking with the right paths (make VERBOSE=1)?

[ubolonton]

Thanks! I'll check that out.

[ubolonton]

The problem seems to be the same. It tries to link with /usr/lib/libiconv.dylib instead of /opt/local/lib/libiconv.dylib.

I don't know how to fix it though, since I'm not familiar with cmake.

[TheBB]

Try something like cmake -DCMAKE_PREFIX_PATH=/opt/local ..

[ubolonton]

That works.

Testing fails with this

Running tests...
Test project /Users/ubolonton/Programming/lib/libegit2/build
    Start 1: libegit2_repository
Process not started
 /Users/ubolonton/Programming/lib/libegit2/cask
[permission denied]
1/1 Test #1: libegit2_repository ..............***Not Run   0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.00 sec

The following tests FAILED:
          1 - libegit2_repository (BAD_COMMAND)
Errors while running CTest
make: *** [test] Error 8

[TheBB]

Great. :-)

As for testing I didn't put those instructions in the README at the time. If you have cask installed you should be able to do cask install in the root folder, then cask exec ert-runner to run the tests. make test does more or less just that.

[ubolonton]

Using cask exec ert-runner gives this error instead: Cannot open load file: No such file or directory, libegit2.

[TheBB]

That's very strange. The load-path is tweaked in test-helpers.el, line 1, and there should be a libegit.xyz in the build directory, no?

[ubolonton]

Silly me. I should have remembered this. Shared libs in macOS has .dylib extension, while module-file-suffix is ".so". My own modules have build scripts that create .so symlink.

[ubolonton]

make test still doesn't work, but cask exec ert-runner works now, with 2 failed tests.

[ubolonton]

I think we should set up Travis integration for this now, to iterate faster. They support testing on mac OS.

Integration is pretty simple, like this: https://github.com/ubolonton/emacs-module-rs/blob/master/.travis.yml

[TheBB]

Yep, agree.

I thought Emacs would look for .dylib files by default on Mac.

[TheBB]

https://github.com/TheBB/libegit2/pull/4

Here's a PR for Travis. I fixed some of the OSX build issues in cmake, so it should be easier for you. I suppose you still have to set the prefix path though.

Three tests fail on OSX. In each case libgit returns a path starting with /private which shouldn't be there. Do you know what's up with that?

[TheBB]

Looks like /tmp is a symlink to /private/tmp...

[TheBB]

Tests are passing on OSX and I've added the macports gotcha to the readme.

Thanks for helping with this. :-)

[ubolonton]

🎉

[Lord-Kamina]

EDIT: Readability 😂

I had this same issue; the problem is with cargo trying to use the macports libiconv (although probably same thing will happen with homebrew) instead of the system one.

This can be reproduced, among other things, when a crate adds the package manager tree to the library/include search paths; one common reason it might happen is OpenSSL; because macOS by default ships an old version incompatible with cargo crates. I fixed it by applying several patches on libgit2-sys, libssh2, openssl-sys and openssl-src (I'm not sure whether all of these are actually needed, some are definitely better candidates than others). For my use-case I did it backwards (as I slowly understood the issue) but the first thing I'd try in order to fix this would be to default openssl-sys to the vendored version if on macOS.

[s-kostyaev]

@TheBB for now on mac os build is broken. Instead of libegit2.dylib there is libegit2.so.

[TheBB]

https://github.com/magit/libegit2/blob/master/src/CMakeLists.txt#L6-L10

That was purposeful. From what I could see based on the Travis tests, Emacs on OSX looked for .so files, not .dylib, so I had to override the extension.

Has that changed?

[s-kostyaev]

Emacs on OSX looked for .so files, not .dylib

This is not true. Maybe it's not true in emacs 27 only. But I have this issue.

[TheBB]

Could you PR a fix? I don't have an OSX computer so it's difficult for me to test. I assume safest would be to add a cmake directive to copy the generated file so there's both a .so and a .dylib present. In the linked file there's already one that copies the library to the parent dir, so you can see how it should look like.

[s-kostyaev]

I will try.