[cmake] [c++] use .dylib extension unconditionally on macOS#6418
Merged
[cmake] [c++] use .dylib extension unconditionally on macOS#6418
Conversation
Collaborator
Author
|
Thanks very much! @guolinke could you also comment when you have time? As you might remember more context for why this was first added back in #6418 (review). |
Collaborator
|
I don't remember, but this change looks reasonable to me |
Collaborator
Author
|
Alright thanks for checking, and for the review @borchero ! Let's proceed with this then. |
6 tasks
Contributor
|
This pull request has been automatically locked since there has not been any recent activity since it was closed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Short Description
Proposes the following changes to CMake-based builds of LightGBM:
APPLE_OUTPUT_DYLIBCMake optionlib_lightgbm.dylibon macOSBenefits of these changes
lib_lightgbmworking correctly with tools that use string matching on file extensions to guess file format (instead of examining the magic bytes)find_library()calls or customfind_*()CMake scripts in other projects would be able to findlib_lightgbmon macOSNotes for Reviewers
This is just changing the file name, not the actual format
The shared library LightGBM currently produces on macOS is actually in mach-o format, not ELF. The CMake customization removed in this PR literally just changes the file name.
I couldn't find a strong reason that LightGBM needs to produce a lib_lightgbm.so on macOS
Looks like that was first added in 70c31c0 back in December 2016. @guolinke do you remember why?
The
APPLE_OUTPUT_DYLIBoption was then added in #204.Why call this "breaking"?
Changing this filename could cause the following types of problems for applications depending on LightGBM on macOS:
lib_lightgbm.sowill no longer find itlib_lightgbm.soin environment variableLD_PRELOADwill no longer workIn my opinion, these are worthwhile costs in exchange for the benefits.
How were these particular changes identified?
I searched like this:
I believe I've caught all the places that need to be changed. Thankfully this project has pretty good CI coverage on macOS (including Python, R, and SWIG), so I think we can be confident that this is working whenever CI for all macOS jobs passes.