Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build error "cannot link directly with dylib/framework" on MacOS Catalina #13

Open
CloudNiner opened this issue Mar 12, 2020 · 13 comments

Comments

@CloudNiner
Copy link
Contributor

I followed the install instructions for MacOS on Catalina. I have openssl installed via brew and also ran xcode-select --install.

When I run:

cmake -v -DCMAKE_BUILD_TYPE=Release -DOPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl/1.0.2s/include/ .

I get the error:

[ 62%] Built target s2
[ 62%] Building CXX object CMakeFiles/osmxTest.dir/test/test_region.cpp.o
[ 62%] Building CXX object CMakeFiles/osmxTest.dir/src/region.cpp.o
[ 62%] Linking CXX executable osmxTest
ld: cannot link directly with dylib/framework, your binary is not an allowed client of /usr/lib/libcrypto.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [osmxTest] Error 1
make[1]: *** [CMakeFiles/osmxTest.dir/all] Error 2
make: *** [all] Error 2

The up to date version of openssl on Catalina is openssl@1.1 1.1.1d, so I also tried using the include path for that version above, e.g.:

cmake -v -DCMAKE_BUILD_TYPE=Release -DOPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl@1.1/1.1.1d/include/ .

and got the same error. I tried omitting the openssl include dir option entirely, and also got the same error.

@bdon
Copy link
Member

bdon commented Mar 13, 2020

thanks for the report - haven't dug into this yet but it looks like the same issue as google/s2geometry#87 - presumably need to link against brew openssl instead of system one

Will also work on updating the binary releases

@bdon
Copy link
Member

bdon commented Mar 13, 2020

@CloudNiner

I uploaded a new macOS binary here: https://github.com/protomaps/OSMExpress/releases/tag/0.0.4

I suspect this problem can be isolated by getting s2geometry to compile. It's difficult for me to reproduce though as I'm on MacPorts instead of Homebrew. Can you try building https://github.com/google/s2geometry - It should be cloned already in vendor/s2geometry ?

I suspect you may need to pass some configuration flags like this https://stackoverflow.com/a/16249265 to get S2's cmake to find the brew openSSL

@CloudNiner
Copy link
Contributor Author

Sorry about the delay in responding. Ultimately I was unsuccessful in getting a build on Catalina. The s2geometry issue you linked states that after a brew upgrade openssl that the build should just work, which is not the case for me -- I've already got the latest openssl installed via brew.

Then I tried building s2geometry following vendor/s2geometry/README.md:

cd vendor/s2geometry
mdkir build
cd build
cmake -DOPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl@1.1/1.1.1d/include/ ..
make

which fails with

/Users/cloudniner/src/OSMExpress/vendor/s2geometry/src/s2/s2shapeutil_testing.cc:20:10: fatal error: 'gtest/gtest.h' file not found

Which is expected since the README told me to install gtest. As far as I can tell there's no brew package for gtest so that's where I stopped rather than building from source and further complicating install.

I was also unable to run the pre-built binary you uploaded as 0.0.4, which failed with the error:

dyld: Library not loaded: /opt/local/lib/libssl.1.1.dylib
  Referenced from: /Users/andrew/bin/osmx
  Reason: image not found
[1]    48461 abort      osmx

I found this stackoverflow which suggests using install_name_tool on the binary. No luck with that either. Looks like homebrew removed openssl 1.0 formula: aisingapore/TagUI#635. Their workaround suggests curling a ruby script but I don't want to wreck my homebrew install so that's where I stopped on this one.

@CloudNiner
Copy link
Contributor Author

Instead of continuing with MacOS install woes I wrote a minimal Dockerfile based on Ubuntu 18.04. This image is 74mb in size so its definitely bigger than the executable, but its not unwieldy. If this is useful, I'd be happy to open a PR to add it to the repo.

@bdon
Copy link
Member

bdon commented Mar 24, 2020

@CloudNiner when building S2 can you use make s2 instead of make which should ignore the test-related targets?

Thanks for the docker file example - can you verify that the Docker image works correctly on a large file e.g. osmx expand planet.osm.pbf planet.osmx

@CloudNiner
Copy link
Contributor Author

can you verify that the Docker image works correctly on a large file

How big is the expanded planet.osmx? My computer only has a 256gb drive.

@bdon
Copy link
Member

bdon commented Mar 24, 2020

Ultimately I think it's a shame that S2 depends on OpenSSL just for its Bignum class. Maybe it won't be too difficult to port it to a standalone library.

google/s2geometry#8

@bdon
Copy link
Member

bdon commented Mar 24, 2020

can you verify that the Docker image works correctly on a large file

How big is the expanded planet.osmx? My computer only has a 256gb drive.

It's about 600 GB.

@CloudNiner
Copy link
Contributor Author

:( I don't think I can run on the planet file then.

can you use make s2 instead of make

That fails with

[100%] Linking CXX shared library libs2.dylib
ld: cannot link directly with dylib/framework, your binary is not an allowed client of /usr/lib/libcrypto.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [libs2.dylib] Error 1
make[2]: *** [CMakeFiles/s2.dir/all] Error 2
make[1]: *** [CMakeFiles/s2.dir/rule] Error 2
make: *** [s2] Error 2

@CloudNiner
Copy link
Contributor Author

PS I commented on the closed s2 issue you linked originally since it looks like we've gone full circle

@bdon
Copy link
Member

bdon commented Mar 24, 2020

@CloudNiner If the Dockerfile is working well for your use case, can you open a PR so I can add it to the repo?

@bdon
Copy link
Member

bdon commented Mar 24, 2020

@CloudNiner thanks. I added (experimental) next to Docker in the readme as I don't have any production experience running osmx inside it; two concerns pop out immediately

  1. the way the database (lmdb) works is by mmaping the entire DB into memory, I'm not certain how this interacts with the Docker runtime - but if you're able to make this work for a extract it should be fine
  2. Also, it should be fine in the non-Docker case if multiple processes open the same .osmx file simultaneously - the locking and transactions should be handled by the lmdb code but I'm not sure if this works correctly with docker and the filesystem

If you have success using it in Docker can you post it here?

@CloudNiner
Copy link
Contributor Author

Those are great points, thanks for the heads up.

I only got as far as generating an osmx file last night, which worked fine. It may be a bit until I have time to go further with this but I'll report back when able. Thanks for all your quick responses!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants