Boost 1.86 SHA1 compatibility fix #69
Conversation
jmakovicka
requested review from
aldanor,
jameslamb,
synapticarbors and
xhochy
as code owners
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe/meta.yaml:
This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13292814680. Examine the logs at this URL for more detail. |
|
@conda-forge-admin please rerender |
| + buf << std::hex << std::setfill('0') << std::setw(sizeof(digest[0]) * 2) << digest[i]; | ||
|
|
||
| return buf.str(); | ||
| } |
There was a problem hiding this comment.
I think this is ok, but writing out my reasoning to be sure I'm understanding correctly.
The file you're patching here is in LightGBM's vendored copy of the Boost 1.74 headers.
But here in conda-forge, lib_lightgbm is dynamically linking against the latest libboost-devel (1.87.0 as of this writing).
- https://github.com/conda-forge/lightgbm-feedstock/blob/bca9f5edeb5f98a93af27579102a5a46b914eeed/recipe/boost_shared.diff
lightgbm-feedstock/recipe/meta.yaml
Line 38 in bca9f5e
So this allows LightGBM to be built successfully, by pulling forward a specific breaking change in Boost (the one @sofiageo mentioned in microsoft/LightGBM#6786 (comment)).
Right?
If so I'm ok with that. But this is a fragile state to be in (vendoring headers from a version and then linking against a shared library from a different version).
If you know how to get LightGBM building successfully with Boost 1.87, we'd welcome help upstream (cc @StrikerRUS): microsoft/LightGBM#6582
And also longer-term, LightGBM should really be modified upstream to stop vendoring these headers and to instead expect them to be provided in the build environment (maybe as part of microsoft/LightGBM#6774).
There was a problem hiding this comment.
The file you're patching here is in LightGBM's vendored copy of the Boost 1.74 headers.
But here in conda-forge,
lib_lightgbmis dynamically linking against the latestlibboost-devel(1.87.0 as of this writing).
According to the logs, boost 1.86 is used for during build (and present in the resulting index.json).
So this allows LightGBM to be built successfully, by pulling forward a specific breaking change in Boost (the one @sofiageo mentioned in microsoft/LightGBM#6786 (comment)).
Right?
Yes, the only difference is that my version works with both pre- and post-1.86 boost. The above PR works with >=1.86 only.
If so I'm ok with that. But this is a fragile state to be in (vendoring headers from a version and then linking against a shared library from a different version).
If you know how to get LightGBM building successfully with Boost 1.87, we'd welcome help upstream (cc @StrikerRUS): microsoft/LightGBM#6582
I didn't try 1.87 yet, because most of conda-forge is compatible with 1.86 at maximum.
There was a problem hiding this comment.
Ah ok, I see the global pinnings are to 1.84:
And that there's a migration in progress to upgrade packages to 1.86:
recipe/meta.yaml
Outdated
|
|
||
| build: | ||
| number: 4 | ||
| number: 6 |
There was a problem hiding this comment.
| number: 6 | |
| number: 5 |
There aren't any published *_5 packages, so assuming this was a mistake.
…nda-forge-pinning 2025.02.10.18.05.55
|
Changed the patches to
|
Checklist
0(if the version changed)conda-smithy(Use the phrase@conda-forge-admin, please rerenderin a comment in this PR for automated rerendering)