Ran into this situation where I’d assume that the correct “libstdc++6-devel” package would be selected based on the already installed gcc version, but it’s not happening… Or at least it hasn’t been apparent to me.
So, for instance if I have gcc7 already installed, there seems to be no way to automatically install the correct libstdc++6-devel package(there are currently packages for gcc7 and gcc8).
For now, I squashed the ant with an elephant by installing the entire “devel_C_C++” pattern (which installs over 160 unneeded packages). After verifying that works, I’m next considering just installing both/all libstdc++6-devel" packages.
But, I’m just a bit surprised that there might not be a hook for the devel package to use for determining whether it’s the correct devel package or not. I can’t remember specifics, but it seems to me I think I did run into instances in the past where if I installed a devel package, the proper binary or library was installed if it wasn’t already.
I took a few minutes looking at hacking package names for their versions, but decided to set that aside for now.
This is somewhat important for what I’m doing because I’m writing an install script intended for public use I want to be as durable as possible supporting past, current and future versions which makes this automatic detection necessary for automation.
Some minor quibbling, both gcc7-c++ and gcc8-c++ require vendor changes for packages to be installed which aren’t even required for this use. Sure, the immediate solution is to set the “–allow-vendor-change” option, but this is worrisome for the future, it suggests that if this, then other special allowances might be necessary… requiring personal intervention and maintenance.
AFAICT the C Development pattern that’s configured now doesn’t seem to require things like vendor changes.
And, it seems that the “-y” or “–no-confirm” option that puts the installation into non-interactive automated mode can’t automatically select the recommended option for any multiple choice issue that comes up, it only works for yes/no issues.
Ordinarily things like this aren’t big enough to be concerned about, but do become issues when you are building something that can’t/shouldn’t be touched again unless it can’t be avoided.
Some minor quibbling, both gcc7-c++ and gcc8-c++ require vendor changes
for packages to be installed which aren’t even required for this use.
Sure, the immediate solution is to set the “–allow-vendor-change”
option, but this is worrisome for the future, it suggests that if this,
then other special allowances might be necessary… requiring personal
intervention and maintenance.
AFAICT the C Development pattern that’s configured now doesn’t seem to
require things like vendor changes.
And, it seems that the “-y” or “–no-confirm” option that puts the
installation into non-interactive automated mode can’t automatically
select the recommended option for any multiple choice issue that comes
up, it only works for yes/no issues.
Ordinarily things like this aren’t big enough to be concerned about, but
do become issues when you are building something that can’t/shouldn’t be
touched again unless it can’t be avoided.
TSU
Hi
Then you must have some other repositories enabled that are not
standard?
What openSUSE release are you working with?
Normally installing gcc and gcc-c++ (which are soflinks to the release
default gcc/c++) for example if I install the above for Tumbleweed gcc8
and gcc8-c++ are installed, if I want another version if not using
update-alternatives is to export CC and CXX to the desired version in a
spec file or script… in a script you could set an option on which
compiler to use fir example;
#!/bin/bash
if (( $# != 1 )); then
echo "Usage: $0 <COMPILER_VERSION>" >&2
exit 1
fi
COMPILER_VERSION="$1"
echo $COMPILER_VERSION
echo "CC=`which gcc-$1`"
echo "CXX=`which g++-$1`"
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.25-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Thx for posting your code,
I was just looking at needing to do that when I decided to first verify that a natural, existing relationship between the compiler and its dependency packages didn’t already exist (IMO there should be which should make the coding unnecessary).
For some reason,
I experienced different behavior on a LEAP 15…
First, I installed the gcc7-c++ package and surprisingly found it didn’t install gcc7 despite its listing in the package contents. After running the install script a few times and getting the same result, am assuming short of a real error in the package, it might be caused by racing threads in a scripted install… I resolved simply by explicitly listing gcc7 separately. And, it required downgrading a package (I’d have to back-track to identify exactly what package it was). gcc8 was an impossibility, it required complete de-installation of some needed packages.
But yes, the install script is trying to support both TW and LEAP, and I’m trying to support not just current versions but the next version whenever possible.
And yes, additional non-standard repos are used, the gcc repo (for reasons that escape me at the moment), the science repo and optionally the machine learning repo.
I’ve posted my current draft publicly at
Go ahead and run it in a throwaway VM to see how it works…
Although it still has some work to do to hook up to a chessboard (It’s a chess engine like Stockfish),
In its current form it should run very nicely on LEAP 42.1-15.1 (depending on availability of repos and packages) and Tumbleweed. It might even work on an ARM like RPi (It’s not on my list of target platforms to be tested but AFAIK should work).
The skeleton logic for the OS detection and inserting version numbers in repository URLs you see in the script is in my updated Wiki