I upgraded from 42.3 to 15. I appreciate that 15 supports the later version of gcc 7.3, but in 42.3 prior versions of gcc were supported such as 4.8, 5.3., and 6.2. Is it possible to install any of these prior versions of gcc on 15 ?
Possibly, unfortunately, you may have to build the earlier GCC versions from source: <http://mirrors.kernel.org/gnu/gcc/>.
There is a “recipe” on Stackoverflow which may, or may not, be OK – you may experience conflicts with Leap 15.0’s GCC 7 … :
wget ftp://mirrors.kernel.org/gnu/gcc/gcc-4.9.0/gcc-4.9.0.tar.gz
cd gcc-4.9.0
./contrib/download_prerequisites
cd ..
cd gcc-build-4.9.0
../gcc-4.9.0/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib
make -j4 (wait for 40 min)
make install
Yes, yes, I know, previous compiler versions are sometimes needed to maintain existing applications but, IMHO, it is better to try and keep a system with the appropriate compiler version installed up and running for as long as the concerned application needs to maintained … « If you see what I mean … ».
currently only gcc7.3 and gcc8.1 are available for LEAP 15.0
http://download.opensuse.org/repositories/devel:/gcc/openSUSE_Leap_15.0/
while 3.3 4.8 7.3 and 8.1 are available for 42.3
http://download.opensuse.org/repositories/devel:/gcc/openSUSE_Leap_42.3/
you could open a bug report and ask for those older compilers be made available for 15.0
https://bugzilla.opensuse.org/
or build them manually
you can switch between gcc compilers using update-alternatives
You can get your ancient files including gcc from archived packages for old openSUSE versions
https://ftp5.gwdg.de/pub/opensuse/discontinued/distribution/
Installing an ancient gcc package should be fairly safe, even from another distribution or openSUSE version… gcc binaries are generally standalone without any dependencies.
After you’ve installed your gcc,
You can then set up an update-alternatives to switch your system between gcc.
Again, this should generally be safe because a compiler is used only when compiling… and that should happen only on rare occasions. Source generally needs to be compiled only once and not again.
But still, I’d recommend that once you’ve compiled with a non-default gcc, when done you should switch back.
For some software, you don’t have access to the source spec file or in practically all cases it’s just more convenient to switch the entire system instead of editing lines in a spec file.
My Wiki page describing how to create an update-alternatives for gcc
https://en.opensuse.org/User:Tsu2/gcc_update-alternatives
If you’re really paranoid, you can run the gcc binary in a virtual machine or container.
HTH,
TSU
I think you mean ‘5.3’, not ‘3.3’, above. I understand I can build them manually. In the previous 42.3 there was no need for update-alternatives if I just used g+±4, g+±5 etc. when I needed to use the non-default version of gcc. I am a bit surprised that Leap 15.0 dropped these earlier versions, but it is OK and I can live without them. The only reason I like a number of earlier compiler versions of gcc ( and clang ) is because I need to test software on different versions of compilers.
with a filename gcc33-3.3.3-34.1.x86_64.rpm I’m guessing that’s gcc 3 3.3.3 not 5.3 but I could be wrong
Are you saying I can download an rpm file for some gcc version from a previous release of OpenSuse and install it in 15.0 using zypper or Yast ? I don’t update-alternatives myself as long as the compiler is g+±n, which it always has been when multiple versions are installed.
OK, thanks ! I realize I can build from source but I hate to go that route myself because of all the options I need to configure in some way. When OS offers a version I do not have to think about the options.
Yes.
But after thinking about this more, you should install a package that’s not <just> gcc, as you already know you want a gcc binary that specifies the version.
So,
You may want to inspect the contents of the RPM to verify that a gcc without version is not installed, else you should extract the files to an alternate site and then rename the gcc binary so that it doesn’t over-write existing files. The following command lists the contents of the RPM
rpm -ql *package_name*
Or, if you accidentally over-write LEAP 15’s default gcc, just “force re-instal” the package, eg
zypper in -f gcc
As for whether you need to install a gcc update-alternatives or not, it depends on what you’re doing. If you’re able to specify your choice of gcc by command line or spec file, then good for you. But sometimes a bigger application will run an install without giving the User a way to specify the gcc, and in that situation you have no choice but to do something like update-alternatives (an alternative is to rname gcc files so that the install can find the correct gcc).
TSU
I found the latest packages for gcc4, gcc5, and gcc6 for Leap 42.3 on the website https://pkgs.org/. None of these packages, according to ‘rpm -ql’ , overwrite the main gcc package. I will try to install each one, for gcc c and gcc c++ into Leap 15.0. That https://pkgs.org is a wonderful website.
You could also take a look at the following Leap 42.3 repository: <http://download.opensuse.org/repositories/devel:/gcc/openSUSE_Leap_42.3/x86_64/>.
- gcc33 and gcc48 …
BTW: ’ > rpm --query --list --file «file name of the downloaded RPM package» ’ …
[HR][/HR]Be that all as it may, I’m still not convinced that, it’s a good idea to attempt to maintain «old code» which needs «old compiler versions» with a «newest, latest, up-to-date» system which doesn’t really support the compiler versions needed to maintain the code to be maintained …
- There’s too much danger in the compiler and library dependencies to ensure a reliable and correct maintenance process, IMNSHO …
Therefore, I maintain my view that, if «old» code, which requires «old» compiler versions has to be be maintained then, it’s usually more reliable, with verifiable results, to use an «older» system (with the last available patches installed) to perform the maintenance …
- Given that, the maintenance team are using an isolated network segment ( which they should do anyway … ) the chances of a “security issue” due to the «old» system version are, IMNSHO, negligible – read, can be safely ignored …
[HR][/HR]Not the Originator]:
Please note that, there are situations where «old» code cannot be ported to matched to the current supported compiler version(s) for whatever reason and, therefore, «old» systems need to be kept available for any maintenance needed …
To my eye,
The danger still exists in this package repository, it’s probably hardly different from any other that is likely a mirror of what once existed. There is no reason for anyone to modify or remove any packages.
So,
Again beware of packages which might over-write <defaults>.
Packages which only add without changing defaults are the only ones that are “safe.”
Else,
- Install and use the update-alternatives as I described, you can set gcc persistently regardless what is default
- Do a “force install” of your gcc which should over-write anything that’s been modified.
TSU
If you have created a library for others to use it is often the case that you must maintain that library with different compiler/versions, and not just the latest version(s) offered by a particular compiler. I am a Boost C++ developer so it is often important that I test code with earlier versions of compilers. Of course if you are creating an application strictly for your own use there is generally little problem using the latest version(s) of a compiler.
OpenSuse previous to 15.0 did support some older versions of gcc. I can understand that they have dropped that support, but that does not solve my need. Other Linux distros do support some older versions of gcc, starting with 4.x on up through 7.3 and/or 8.1. I do not blame OpenSuse for not wanting to do so, but it is unfair to be criticized for attempting to solve my own problem when there is a totally valid reason for wanting to be able to install earlier versions.
Each of the versions above installs all files to version specific directories or creates version specific filenames. I do not see how such actions can override defaults. None of them replace /usr/bin/gcc or /usr/bin/g++ or any supporting files for the default version of gcc/g++.
I think you’re looking at the wrong things.
As you describe, you should always see each gcc version in its own directory, and each of these gcc can be invoked by specifying the <exact> binary final name, but what about the default when you simply invoke gcc without specifying a specific version?
In each openSUSE release, there will be one gcc which will be configured as the default where gcc (no version specified) will point (possibly link) to a gcc in its own directory.
This means that if you install one of these “default gcc” packages from an old version of openSUSE, you will likely change the default and this can have consequences… GPU modules are often compiled on the fly during boot, other kernel modules and apps might also be built automatically and you will want those built with the gcc that’s recommended for your openSUSE (nowadays likely LEAP 15 or TW). You don’t want to be building modules with a gcc that was default for LEAP 42.1 or even 13.2 or earlier.
So,
As I described, I highly recommend you take care not to leave your system with a non-default gcc configured as your default by accident.
TSU
All three packages are from 42.3. Are you saying that OpenSuse will somehow replace the default gcc with one of these if I install it in 15.0 ? If so how can I know in advance if this will happen ? As I explained the rpm itself for each of these packages shows the filenames for gcc and g++ as gcc-n and g+±n and not as gcc and g++ along with support files in directories of somedirectory’n’ and not the equivalent somedirectory of the default gcc or g++. So why would an attempted install of one of these earler versions of gcc/g++ from Laep 42.3 install itself as the default gcc/g++ on 15.0 ?
If you inspected the package contents and didn’t find a generic gcc file, you should be OK with those packages.
As I described in my Wiki, you can always doublecheck by querying your system default
gcc --version
TSU
Yes!
And, therefore, my suggestion is, that, you should attempt to have more than a few, physical, platforms running with the last available patches/updates of «older» operating systems with the (from then) supported GCC versions – for testing purposes – forget about the security implications – you’re maintaining a test environment/laboratory – which should be isolated from the rest of the world anyway …
- Putting my ISTQB certified Tester hat on: AFAICS it’s not a good idea to attempt to run a test environment which «needs» older GCC versions on «newer» platforms which do not support the «older» compiler versions …
Please note that, the support for openSUSE Leap 42.3 has been extended – news out today at 14:19 Central European Summer Time:
- "openSUSE Leap 42.3 End of Life is Extended
": <https://news.opensuse.org/2018/08/08/opensuse-leap-42-3-end-of-life-is-extended/>
[HR][/HR]openSUSE News: <https://news.opensuse.org/>.
I dunno…
People who have seen a list of vms in my vm manager have often remarked about the long list…
And I do absolutely run all my development in virtual machines (because they break) and to isolate environments to prevent cross-contamination,
But if a gcc version build is the only diff between what is done,
I wouldn’t likely create a whole vm just for that kind of test because it’s too easy, almost trivial to run each test without contamination.
TSU