Project

General

Profile

Actions

Bug #10348

closed

Weed out MPFR, MPC, & GMP sub-components from GCC components

Added by Michal Nowak over 3 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
OI-Userland
Target version:
Start date:
2019-02-06
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Our GCC components use MPFR, MPC, & GMP sub-components during the build.

Those sub-components are out-dated.

System-wide MPFR, MPC, & GMP should be used instead, where possible, or, at least, sub-components updated.

Special regard should be payed on what MPFR, MPC, & GMP version particular GCC supports (if there's such a limitation).

https://gcc.gnu.org/wiki/InstallingGCC

Do we need this https://build.opensuse.org/package/view_file/devel:gcc/gcc8/gcc48-remove-mpfr-2.4.0-requirement.patch?expand=1 ?

Actions #1

Updated by Aurélien Larcher over 3 years ago

This was a design decision to avoid breakage of the compiler if the update of one of the dependencies went wrong.
Also older compiler version may rely on specifics from older MPFR, MPC, GMP.
Factoring is nice but eggs may not be kept in the same basket ;)

I would rather keep the current setup and update the compiler separately whenever needed.
I did not do it for the latest MPFR given that one test failed and I did not have time to investigate.

The other point is that having slightly outdated MPFR, MPC, GMP is not really a problem that does not justify adding a dependency from the main compiler to userland libs for convenience.

In general my humble opinion is that we do not have the resources of commercial Linux distributions so we should be a bit more conservative, even if it means recompiling the same libraries twice (it does not cost much).

Actions #2

Updated by Alexander Pyhalov over 3 years ago

  • Status changed from New to Rejected

I close this. It is a feature, not a bug, as Aurelien has explained.

Actions

Also available in: Atom PDF