Support SCIP installations under lib64#47
Merged
Conversation
CMake's GNUInstallDirs installs the SCIP libraries into `lib64` (not `lib`) on 64-bit RHEL/Fedora/SUSE-like systems, but the build script only ever looked in `<prefix>/lib`. As a result both `--features from-source` and SCIPOPTDIR / system installations failed to find SCIP on those distros (panicking with `<prefix>/lib does not exist` or `Could not find SCIP installation`). - Add `find_scip_lib_dir()`, which probes both `lib` and `lib64` for `libscip*`, and route `emit_link_search()` and `lib_scip_in_dir()` through it. The probe order follows the target pointer width (`lib64` first for 64-bit targets) so a 64-bit build does not accidentally pick up a 32-bit libscip that may live in a multilib `<prefix>/lib`. - Pin `CMAKE_INSTALL_LIBDIR=lib` for the from-source build so SCIP is always installed into `<prefix>/lib`, regardless of the host distro's GNUInstallDirs default. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add two jobs covering the `lib64` install layout that CMake's GNUInstallDirs uses on 64-bit RHEL/Fedora/SUSE-like systems: - linux-lib64-scipoptdir-test: re-lays the prebuilt bundled libraries into a `lib64` prefix (plus a bogus `lib/libscip*`) and builds against it through SCIPOPTDIR, exercising lib64 detection and the lib64-first probe order. - linux-lib64-from-source-test: builds `--features from-source` inside a Rocky Linux 10 container, exercising the from-source path on a lib64 distro. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
msakai
marked this pull request as ready for review
June 29, 2026 16:10
Contributor
Author
|
The failure in |
mmghannam
reviewed
Jul 1, 2026
Member
|
Thank you @msakai! |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem
On 64-bit RHEL/Fedora/SUSE-like distributions, CMake's
GNUInstallDirsinstalls libraries into<prefix>/lib64rather than<prefix>/lib. The build script only ever looked in<prefix>/lib, so SCIP could not be found there. Both affected paths fail:--features from-source: SCIP is compiled and installed intoOUT_DIR/lib64, then the build panics with<OUT_DIR>/lib does not exist, please check your SCIP installation.SCIPOPTDIR/ system install: a SCIP installed under$SCIPOPTDIR/lib64is not detected, and the build panics withCould not find SCIP installation.This is what users hit when building on e.g. RHEL / Rocky / AlmaLinux. On Debian/Ubuntu (which keep
lib), the build works, which is why this had gone unnoticed.Changes
libandlib64(find_scip_lib_dir), and routeemit_link_search()andlib_scip_in_dir()through it. The probe order follows the target pointer width —lib64first for 64-bit targets — so a 64-bit build doesn't accidentally pick up a 32-bitlibscipthat may live in a multilib<prefix>/lib. (32-bit targets probe onlylib.)CMAKE_INSTALL_LIBDIR=libfor the from-source build so SCIP is installed intoOUT_DIR/libdeterministically, regardless of the host distro'sGNUInstallDirsdefault.The
bundledpath is unaffected (its prebuilt layout already useslib, which the probe still finds).Testing
Two CI jobs are added to cover this going forward:
linux-lib64-scipoptdir-test(ubuntu): re-lays the prebuilt bundled libraries into alib64prefix (plus a boguslib/libscip*) and builds against it viaSCIPOPTDIR, exercising lib64 detection and the lib64-first order.linux-lib64-from-source-test: builds--features from-sourceinside a Rocky Linux 10 container.I added the CI just to be thorough, but I might have gone a little overboard.