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

cmake: Avoid leaking absolute paths into exported config #7152

Closed
wants to merge 1 commit into from

Conversation

@gjasny
Copy link
Contributor

@gjasny gjasny commented May 31, 2021

The find_libarary command resolves the library or framework
into an absolute path. In case of system frameworks which are
located within an Xcode-provided SDK this results in the Xcode
path and SDK version being part of the library path.

Because those library paths end up in the exported CMake config
importing curl will fail once the Xcode location or SDK version
changes:

set_target_properties(CURL::libcurl PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "lber;ldap;/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/SystemConfiguration.framework;OpenSSL::SSL;OpenSSL::Crypto;ZLIB::ZLIB"
)

A work-around is to link against system-level frameworks with
-framework XYZ. In case of SystemConfiguration we might be able
to omit the lookup-check because we could assume the framework is
always present.

@gjasny
Copy link
Contributor Author

@gjasny gjasny commented May 31, 2021

CMakeLists.txt Show resolved Hide resolved
@zajdee
Copy link

@zajdee zajdee commented May 31, 2021

Does this only affect the SystemConfiguration framework or is it relevant to other frameworks, imported the same way?

@bagder bagder added the cmake label May 31, 2021
The `find_libarary` command resolves the library or framework
into an absolute path. In case of system frameworks which are
located within an Xcode-provided SDK this results in the Xcode
path and SDK version being part of the library path.

Because those library paths end up in the exported CMake config
importing curl will fail once the Xcode location or SDK version
changes:

```cmake
set_target_properties(CURL::libcurl PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "lber;ldap;/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/SystemConfiguration.framework;OpenSSL::SSL;OpenSSL::Crypto;ZLIB::ZLIB"
)
```

A work-around is to link against system-level frameworks with
`-framework XYZ`. In case of `SystemConfiguration` we might be able
to omit the lookup-check because we could assume the framework is
always present.
@gjasny gjasny force-pushed the gjasny:darwin-sdk-framework-link branch from 0465b71 to 887ec97 May 31, 2021
@gjasny
Copy link
Contributor Author

@gjasny gjasny commented May 31, 2021

Does this only affect the SystemConfiguration framework or is it relevant to other frameworks, imported the same way?

Thanks. I also fixed-up the remaining two frameworks. Resulting CURLTargets.cmake:

set_target_properties(CURL::libcurl PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "lber;ldap;-framework CoreFoundation;-framework Security;-framework SystemConfiguration;OpenSSL::SSL;OpenSSL::Crypto;ZLIB::ZLIB;/opt/homebrew/lib/libssh2.dylib"
)
@bagder
Copy link
Member

@bagder bagder commented Jun 3, 2021

@zajdee does this change seem fine to you?

@bagder
Copy link
Member

@bagder bagder commented Jun 6, 2021

Thanks!

@bagder bagder closed this in f777e75 Jun 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants