-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Test GLIBC compatibility & Use GLIBC 2.28 w/Linux ARM #34
Test GLIBC compatibility & Use GLIBC 2.28 w/Linux ARM #34
Conversation
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/13003589932. Examine the logs at this URL for more detail. |
…nda-forge-pinning 2025.01.27.18.10.49
d8e397f
to
3869b12
Compare
@conda-forge-admin , please re-render |
…nda-forge-pinning 2025.01.27.18.10.49
Rebuild now that Linux ARM uses GLIBC 2.28.
@carterbox could you please review? |
d64b7b1
to
ae88637
Compare
We're getting unexpected behavior because the top-level and first output are merged. i.e.
|
Demerging those outputs causes(?) the tests for the -dev package to fail. |
Since the top-level package name now is `libcublas-split`, we cannot use `PKG_NAME` in the build script. So add a new variant `component_name` to `conda_build_config.yaml` and use that throughout.
@conda-forge-admin , please re-render |
else | ||
# Put all other files in targetsDir | ||
mkdir -p ${PREFIX}/${targetsDir}/${PKG_NAME} | ||
cp -rv $i ${PREFIX}/${targetsDir}/${PKG_NAME} | ||
mkdir -p ${PREFIX}/${targetsDir}/${component_name} | ||
cp -rv $i ${PREFIX}/${targetsDir}/${component_name} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We were relying on the PKG_NAME
to add some extra bits here. However now they go in libcublas-split
(given that is when this build script runs
Have tried to address this here by creating a new variant/variable to handle this install location
…nda-forge-pinning 2025.01.27.22.18.09
@conda-forge-admin , please re-render |
…nda-forge-pinning 2025.01.27.22.18.09
Stick to a unique variable name instead of clobbering the conda-build value. This is clearer long term.
@conda-forge-admin , please re-render |
Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do. This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13003174999. Examine the logs at this URL for more detail. |
# Run GLIBC check | ||
check-glibc bin/* lib/*.so.* lib64/*.so.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this ok for a check? Or do we need to do anything additional here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The `RECIPE_ROOT` variable was not set after moving the tests into the package name. However this is not needed anyways as we already instruct `conda-build` to copy the test file into the test directory. So it should already be in the current working directory. Given this, just drop it.
This fixes an issue where the GLIBC 2.17 sysroot would otherwise be pulled in.
@conda-forge-admin , please re-render |
Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do. This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13003456521. Examine the logs at this URL for more detail. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM assuming that the missing DSO warnings about libgcc and stdlibc++ are expected due to the targets directory.
Thanks Daniel! 🙏 Yep these are not new warnings. For example we see the same thing on |
{{ stdlib("c") }}
in the compilation test (and drop a related workaround)check-glibc
os_version
(as this is sufficiently handled by the above changes)Fixes #13