In the last couple of days when doing an update with Yast I was offered a new set of gcc* version 8* items.
Once these were installed a number of gcc version 7 items were flagged red in Yast listing so I assume that these are no longer available to me.
However when I try to delete these I am informed that this will break various important packages like Python, so I have just left them be.
One item that was not updated was the main symbolic link gcc -> gcc-7 so I changed this to gcc -> gcc-8.
Since then I have performed some compile updates and all seems to be well so there is no complaint here;
just that I am left puzzled why I was not carried wholesale from v 7 to v 8.
Anyone else experience the same thing?
Without better details about your python errors if you remove your gg7, that sounds really odd to me… AFAIK gcc really is a C compiler so AFAIK should be completely unrelated to anything python.
Also,
Should you decide to keep multiple gcc on your system, instead of modifying the symbolic link as you did in a ratatively static manner, I’d recommend instead that you create an “alternative” so you can switch between your gcc easily.
I created a Wiki page describing how to do this…
https://en.opensuse.org/User:Tsu2/gcc_update-alternatives
TSU
Agreed; I think the problem arises when trying to add libraries to Python that require compilation.
Thanks for this suggestion. I’ll take a look at it.
I’m sure it is an abundance of caution that left the link to the old set of programmes.
One of my concerns is that there might be other symbolic links to attend to.
Thank you, I find the tutorial for alternative installations very interesting.
Just one question; since you have one main program (gcc), but other secondary programs (like for instance gcc-ar, gcc-nm, gcc-ranlib),
would it make sense to perform an --install for the gcc program and then define as slaves (with the option --slave) the other secondary programs?.
Thanks.
You would, particularly if you were a true hardcore C Developer.
If you were a real coder with full knowledge of your source, then you might instead define your compiler parameters in your spec/make file,
But the typical person who frequents these Forums and needs to use a particular gcc version most often needs only the main binary functionality, and none of those others.
TSU
Two days later and Yast update offered me a whole bunch more gcc8 material.
As before, after the update, any attempt to delete the remaining gcc7 components results in warnings; not about python this time but X11, an equally important component of modern Linux installations.
Perhaps there is more to come. It’s all rather confusing.
No confusion here:
erlangen:~ # zypper se --installed-only gcc
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-----------------------+-------------------------------------------------------+--------
i+ | gcc | The system GNU C Compiler | package
i+ | gcc-c++ | The system GNU C++ Compiler | package
i+ | gcc-locale | The system GNU Compiler locale files | package
i+ | gcc7 | The GNU C Compiler and Support Files | package
i | gcc8 | The GNU C Compiler and Support Files | package
i | gcc8-c++ | The GNU C++ Compiler | package
i+ | gcc8-fortran | The GNU Fortran Compiler and Support Files | package
i | gcc8-locale | Locale Data for the GNU Compiler Collection | package
i+ | libgcc_s1 | C compiler runtime library | package
i | libgcc_s1-32bit | C compiler runtime library | package
i+ | libstdc++6-devel-gcc7 | Include Files and Libraries mandatory for Development | package
i | libstdc++6-devel-gcc8 | Include Files and Libraries mandatory for Development | package
erlangen:~ # type gcc
gcc is /usr/bin/gcc
erlangen:~ # readlink -f /usr/bin/gcc
/usr/bin/gcc-8
erlangen:~ #
gcc already linked to gcc-8.
I finally managed to resolve this issue by using the online Leap 15.0 repos for the packages flagged red.
Evidently at some point my cpp7 packages were upgraded from a 7.3 version to a 7.4 but then the 7.4 was withdrawn
or at least not promoted to the online repos.
By a forced reinstall from the online repos of the original 7.3 versions this cleared the red-flagged items from the Yast list.
It was a bit painful to go through the items one by one, but fortunately the list was short, about 10 items.
Yast is now clear and back to normal.
This seems to be correct. There was a message about that in one of the mailing lists.
And I have those withdrawn updates installed here. If I use
zypper dup --dry-run
it shows them as needing to be downgraded. At the moment, it is not causing problems, so I’m not doing anything about it.
Agreed, changing things might not be necessary, it just makes things untidy.
One odd thing, in my list of 10 items there was one item that offered a downgrade to a previous version, which I followed.
None of the others offered this downgrade path, so it was a matter of doing them severally.
When you right-click, there should be an option to “update-unconditionally”. And that should take you to the latest version in the repos, which would be a downgrade in this case.
Yes, as I noted there was one item where that option was available, however for the cpp* items there was no downgrade possible in Yast
apart from forced overwrite from software.opensuse.org sources. The only option offered in Yast was “delete” which would lead to big problems.
Grepping for “gcc8” in “/var/log/zypp/history” revealed that, “gcc8-debugsource” was last installed on this system at the timestamp date “2019-03-29”.
No, just because the packages have been marked with an accent colour, doesn’t mean that “they’re not available” – you should have checked the “version in use” against the “version in the repository”
- If you were to check the YaST Software tab “Repositories” and then choose “@System” and then sort the “Installed (Available)” column, you’ll see all the packages on your system which either need to upgraded or, downgraded
…
I can tell my case. This might be related to the issue reported here.
In my case I use to update zypper. Normally I use these two commands:
zypper lu
zypper update
Yesterday I realized that at some point some packages were upgraded, and they were linked
to no-repository:
zypper search -s |grep "System Packages"
The output of this command is:
i | cpp7 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i+ | cque-en | package | 4.0-1 | x86_64 | (System Packages)
i+ | gcc7 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i | gcc7-fortran | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i | libasan4 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i | libcilkrts5 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i | libgfortran4 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i | libgnutls30 | package | 3.6.2-lp150.4.3.1 | x86_64 | (System Packages)
i | libstdc++6-devel-gcc7 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
i | libubsan0 | package | 7.4.0+r266845-lp150.3.3.1 | x86_64 | (System Packages)
To me the fact that these packages were upgraded is OK. However, I do not understand why they do not belong to any repository,
just to “System Packages”.
A part from that, everything seems to work normally.
Thanks
Yes, I’m seeing that on one computer (but not on others).
I saw an explanation, I think on one of the mailing lists. There was an update to “gcc7”. But the update was pulled (removed from the update repo) because of some temporary problem it was causing. So I have those packages from the pulled update on the one system that I updated just before the update was pulled.
I expect the same happened to you. If it isn’t causing problems, then don’t worry about it.
Thank very much for the explanation; now it makes sense.
I also found this thread:
https://lists.opensuse.org/opensuse-factory/2019-03/msg00344.html
It says that the update caused i586 failures.
Cheers.
Meaning that, this Post’s originator should forcibly re-install all the GCC 7 packages installed on the affected system(s) …
I don’t think that is needed if everything is working.
On my system, if I use
zypper dup --dry-run
it tells me that it wants to downgrade those gcc7 related packages. Of course, with the “–dry-run” it doesn’t actually do anything.
I’ve noticed just now that, YaST, when it marks packages with the colour red, currently doesn’t downgrade them – I seem to recall that, it used to – possibly, only with a Repository change – for example from Packman to openSUSE …
It will downgrade with “zypper dup” but not with “zypper up”. And a repo change uses “zypper dup”, though restricted to the one repo.