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

Add capnproto/0.9.1 #7429

Merged
merged 4 commits into from
Sep 28, 2021
Merged

Add capnproto/0.9.1 #7429

merged 4 commits into from
Sep 28, 2021

Conversation

tuxu
Copy link
Contributor

@tuxu tuxu commented Sep 27, 2021

Specify library name and version: capnproto/0.9.1

Adds version 0.9.1, which contains numerous bugfixes and includes most patches that were previously applied for the build of this recipe.

The only remaining patch is to disable tests for the autotools build. Not sure whether this is still needed. Possibly to avoid issues when cross-compiling?


  • I've read the guidelines for contributing.
  • I've followed the PEP8 style guides for Python code in the recipes.
  • I've used the latest Conan client version.
  • I've tried at least one configuration locally with the
    conan-center hook activated.

@CLAassistant
Copy link

CLAassistant commented Sep 27, 2021

CLA assistant check
All committers have signed the CLA.

@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

@tuxu
Copy link
Contributor Author

tuxu commented Sep 27, 2021

Building the tests on macOS/M1 with capnproto:shared=True fails. This is unrelated to my changes, but we nevertheless need to fix it ;)

The build fails while calling the capnp utility:

dyld: Library not loaded: /Users/jenkins/w/BuildSingleReference@3/.conan/data/capnproto/0.9.1/_/_/package/040ddf5d579b3bc9e742c22482f7734658dec09e/lib/libcapnpc-0.9.1.dylib
  Referenced from: /Users/jenkins/w/BuildSingleReference@2/.conan/data/capnproto/0.9.1/_/_/package/040ddf5d579b3bc9e742c22482f7734658dec09e/bin/capnp
  Reason: image not found
...

Note the subtle difference @3 vs @2 here. It looks like the capnp binary contains a reference to the absolute path of the dylib, not a path relative to the binary (using rpath).

Interestingly, this is a problem with the x86_64 binaries that are pulled in a a build dependency (CI seems to be cross-compiling from x86_64 to armv8 on a native M1 machine):

Configuration (profile_host):
[settings]
arch=armv8
build_type=Debug
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
os=Macos
[options]
capnproto:shared=True
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=12.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]

...

capnproto/0.9.1 (test package): Installing package
Requirements
    capnproto/0.9.1 from local cache - Cache
    openssl/1.1.1k from 'conan-center' - Cache
    zlib/1.2.11 from 'conan-center' - Cache
Packages
    capnproto/0.9.1:8627a254fc6ded11b7547933628a23213ba9cacb - Cache
    openssl/1.1.1k:baf78352c82543f997ec32332829b6fa30714eaa - Cache
    zlib/1.2.11:baf78352c82543f997ec32332829b6fa30714eaa - Cache
Build requirements
    capnproto/0.9.1 from local cache - Cache
    openssl/1.1.1k from 'conan-center' - Cache
    zlib/1.2.11 from 'conan-center' - Cache
Build requirements packages
    capnproto/0.9.1:040ddf5d579b3bc9e742c22482f7734658dec09e - Download
    openssl/1.1.1k:647afeb69d3b0a2d3d316e80b24d38c714cc6900 - Download
    zlib/1.2.11:647afeb69d3b0a2d3d316e80b24d38c714cc6900 - Download

Edit: Best I could come up with is change of $rpath to @rpath and then setting the rpath of the binaries to @loader_path/../lib.

@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

Comment on lines 12 to 16
if self.settings.os == "Macos" and self.settings.arch == "armv8":
# Attempting to use @rpath without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being
# set. This could be because you are using a Mac OS X version less than 10.5
# or because CMake's platform configuration is corrupt.
self.build_requires("cmake/3.20.1")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be moved to the main recipe as the fix for the RPATH problems?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this fix in the test packages for boost and gsl.

The main recipe builds with autotools on Linux/macOS and doesn't require CMake. It seems like the recent version of CMake is just needed on macOS/M1 to build any package depending on libraries with @rpath.

How would it be possible to inject a build_requires on the depending package? Is build_requires from the main package propagated down?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it's cmake bug, and we didn't upgrade cmake on mac slaves (and cannot at the moment, unfortunately)
the workaround should be in test package

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please, add #FIXME to you comment so we can filter it in the future when looking for technical debt

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the #FIXME comment.

@prince-chrismc
Copy link
Contributor

Please do not force push 🙏 GitHub forces us to restart the review which is not fun!

@conan-center-bot
Copy link
Collaborator

All green in build 6 (f1eecb18a2b6ca3215252d19bce6e9140fb540ac):

  • capnproto/0.9.1@:
    All packages built successfully! (All logs)

  • capnproto/0.7.0@:
    All packages built successfully! (All logs)

  • capnproto/0.8.0@:
    All packages built successfully! (All logs)

@conan-center-bot conan-center-bot merged commit 713c824 into conan-io:master Sep 28, 2021
@tuxu tuxu deleted the capnproto-0.9.1 branch September 29, 2021 08:02
@SpaceIm
Copy link
Contributor

SpaceIm commented Feb 19, 2022

Building the tests on macOS/M1 with capnproto:shared=True fails. This is unrelated to my changes, but we nevertheless need to fix it ;)

The build fails while calling the capnp utility:

dyld: Library not loaded: /Users/jenkins/w/BuildSingleReference@3/.conan/data/capnproto/0.9.1/_/_/package/040ddf5d579b3bc9e742c22482f7734658dec09e/lib/libcapnpc-0.9.1.dylib
  Referenced from: /Users/jenkins/w/BuildSingleReference@2/.conan/data/capnproto/0.9.1/_/_/package/040ddf5d579b3bc9e742c22482f7734658dec09e/bin/capnp
  Reason: image not found
...

Note the subtle difference @3 vs @2 here. It looks like the capnp binary contains a reference to the absolute path of the dylib, not a path relative to the binary (using rpath).

Interestingly, this is a problem with the x86_64 binaries that are pulled in a a build dependency (CI seems to be cross-compiling from x86_64 to armv8 on a native M1 machine):

Edit: Best I could come up with is change of $rpath to @rpath and then setting the rpath of the binaries to @loader_path/../lib.

It's worth noting that this is a partial fix. If openssl or zlib are shared, it breaks because they are not located in @loader_path/../lib. Blame Apple for SIP behavior, working against developers.

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

Successfully merging this pull request may close these issues.

None yet

7 participants