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

ABI conflict in test suite on osx-64 #5470

Closed
2 tasks done
kenodegard opened this issue Aug 30, 2024 · 2 comments · Fixed by #5471
Closed
2 tasks done

ABI conflict in test suite on osx-64 #5470

kenodegard opened this issue Aug 30, 2024 · 2 comments · Fixed by #5471
Assignees
Labels
¡blocking! used to indicate a blocker for a pending release in-progress issue is actively being worked on severity::1 blocker; broken functionality with no workaround source::anaconda created by members of Anaconda, Inc. type::bug describes erroneous operation, use severity::* to classify the type type::testing issues about tests or the test infrastructure

Comments

@kenodegard
Copy link
Contributor

kenodegard commented Aug 30, 2024

Checklist

  • I added a descriptive title
  • I searched open reports and couldn't find a duplicate

What happened?

Some of the tests are failing due to an ABI conflict on the osx-64 runners, see https://github.com/conda/conda-build/actions/runs/10602558349/job/29384860323.

This is caused by channel mixing where we end up getting the following installed which causes a conflict:

pkgs/main::conda-libmamba-solver
conda-forge::libmambapy
conda-forge::libmamba
...

The channel mixing is unintentional as the only package we need from conda-forge is xdoctest. There are a few possible solutions here:

  1. explicitly require defaults::libmamba[py], see Explicitly depend on libmambapy #5468
  2. set channel_priority: strict for the test environment creation, see Set strict channel priority #5469
  3. use conda-forge instead of defaults
  4. request xdoctest be built for defaults
  5. do we need xdoctest in the first place, maybe we just remove it? see Remove xdoctest & ignore libgcc for overlinking/overdepending checks #5471
@kenodegard kenodegard added type::bug describes erroneous operation, use severity::* to classify the type source::anaconda created by members of Anaconda, Inc. ¡blocking! used to indicate a blocker for a pending release severity::1 blocker; broken functionality with no workaround in-progress issue is actively being worked on type::testing issues about tests or the test infrastructure labels Aug 30, 2024
@kenodegard kenodegard self-assigned this Aug 30, 2024
@kenodegard
Copy link
Contributor Author

even though we specify:

conda-build/pyproject.toml

Lines 110 to 111 in a666e34

"--xdoctest-modules",
"--xdoctest-style=google",

we aren't actually running xdoctest on the source code since pytest by default only crawls the tests directory

@h-vetinari
Copy link
Contributor

Extracting out something from the logs:

Error while loading conda entry point: conda-libmamba-solver (dlopen(/Users/runner/miniconda3/envs/test/lib/python3.8/site-packages/libmambapy/bindings.cpython-38-darwin.so, 0x0002): Library not loaded: @rpath/libarchive.13.dylib
  Referenced from: <4AC18A07-59AA-3912-83CA-AD44A086503C> /Users/runner/miniconda3/envs/test/lib/libmamba.2.0.0.dylib
  Reason: tried: '/Users/runner/miniconda3/envs/test/lib/libarchive.13.dylib' (no such file), '/Users/runner/miniconda3/envs/test/lib/python3.8/site-packages/libmambapy/../../../libarchive.13.dylib' (no such file), '/Users/runner/miniconda3/envs/test/lib/python3.8/site-packages/libmambapy/../../../libarchive.13.dylib' (no such file), '/Users/runner/miniconda3/envs/test/bin/../lib/libarchive.13.dylib' (no such file), '/Users/runner/miniconda3/envs/test/bin/../lib/libarchive.13.dylib' (no such file), '/usr/local/lib/libarchive.13.dylib' (no such file), '/usr/lib/libarchive.13.dylib' (no such file, not in dyld cache))

The latest libmamba 1.5.8 in conda-forge was built against libarchive 3.7.2, which has a different SOVER than 3.6; default doesn't have 3.7 yet, and so their latest libmamba is built against 3.6; that means the different pieces cannot be co-installed.

I wanted to check where the ABI break came from, because despite channel mixing not being really supported, it does happen frequently, and a lot of effort had gone into making things compatible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
¡blocking! used to indicate a blocker for a pending release in-progress issue is actively being worked on severity::1 blocker; broken functionality with no workaround source::anaconda created by members of Anaconda, Inc. type::bug describes erroneous operation, use severity::* to classify the type type::testing issues about tests or the test infrastructure
Projects
Archived in project
2 participants