Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 642300 - dev-libs/mpc-1.0.3 fails to build against dev-libs/mpfr-4.0.0
Summary: dev-libs/mpc-1.0.3 fails to build against dev-libs/mpfr-4.0.0
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 642338 (view as bug list)
Depends on:
Blocks: 642576
  Show dependency tree
 
Reported: 2017-12-26 12:02 UTC by Perfect Gentleman
Modified: 2017-12-29 10:43 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dev-libs:mpc-1.0.3:20171226-132652.log (dev-libs:mpc-1.0.3:20171226-132652.log,58.67 KB, text/x-log)
2017-12-26 13:30 UTC, Michał Górny
Details
mpc-9999.ebuild (mpc-9999.ebuild,1.02 KB, text/plain)
2017-12-26 13:48 UTC, Perfect Gentleman
Details
mpc-1.0.3-replace-obsolete-mpfr-add_sub-functions.patch (mpc-1.0.3-replace-obsolete-mpfr-add_sub-functions.patch,1.07 KB, patch)
2017-12-26 22:02 UTC, Attila Tóth
Details | Diff
mpc-1.0.3-r1.tar.bz2 (mpc-1.0.3-r1.tar.bz2,36.70 KB, application/x-bzip)
2017-12-26 22:08 UTC, Attila Tóth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Perfect Gentleman 2017-12-26 12:02:45 UTC
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mul_fr.c  -fPIC -DPIC -o .libs/mul_fr.o
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mul_i.c  -fPIC -DPIC -o .libs/mul_i.o
/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mul.c:175:1: error: conflicting types for ‘mpfr_fmma’
 mpfr_fmma (mpfr_ptr z, mpfr_srcptr a, mpfr_srcptr b, mpfr_srcptr c,
 ^~~~~~~~~
In file included from /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mpc.h:25:0,
                 from /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mpc-impl.h:30,
                 from /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mul.c:22:
/usr/include/mpfr.h:731:21: note: previous declaration of ‘mpfr_fmma’ was here
 __MPFR_DECLSPEC int mpfr_fmma (mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_srcptr,
                     ^~~~~~~~~
make[2]: *** [Makefile:536: mul.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mul_si.c  -fPIC -DPIC -o .libs/mul_si.o
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/mul_ui.c  -fPIC -DPIC -o .libs/mul_ui.o
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/norm.c  -fPIC -DPIC -o .libs/norm.o
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/neg.c  -fPIC -DPIC -o .libs/neg.o
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/pow.c  -fPIC -DPIC -o .libs/pow.o
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src -I.. -march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fno-stack-protector -ftree-vectorize -c /tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3/src/out_str.c  -fPIC -DPIC -o .libs/out_str.o
make[2]: Leaving directory '/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3-abi_x86_64.amd64/src'
make[1]: *** [Makefile:462: all-recursive] Error 1
make[1]: Leaving directory '/tmp/portage/dev-libs/mpc-1.0.3/work/mpc-1.0.3-abi_x86_64.amd64'
make: *** [Makefile:373: all] Error 2
 * ERROR: dev-libs/mpc-1.0.3::gentoo failed (compile phase):
Comment 1 Michele Alzetta 2017-12-26 12:19:38 UTC
I have the same bug.
Comment 2 Firas Khalil Khana 2017-12-26 12:43:10 UTC
I'm also encountering this bug when attempting an "emerge @preserved-rebuild" after having synced and updated my system.
Comment 3 octoploid 2017-12-26 12:52:59 UTC
A new mpc release is imminent. dev-libs/mpfr-4.0.0 should be masked 'till then.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2017-12-26 13:30:11 UTC
Created attachment 511642 [details]
dev-libs:mpc-1.0.3:20171226-132652.log

Please remember to attach the complete build log when reporting bugs.
Comment 5 Perfect Gentleman 2017-12-26 13:48:50 UTC
Created attachment 511644 [details]
mpc-9999.ebuild

mpc-9999.ebuild cab be used for some time as workaroud
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2017-12-26 16:10:32 UTC
The upstream fix for symbol collision is: https://scm.gforge.inria.fr/anonscm/gitweb?p=mpc/mpc.git;a=commitdiff;h=36a84f43f326de14db888ba07936cc9621c23f19
Comment 7 Larry the Git Cow gentoo-dev 2017-12-26 16:40:05 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cdf7f5c37e8a3dfacfbf5fc81a6a2a8ef3b77a9a

commit cdf7f5c37e8a3dfacfbf5fc81a6a2a8ef3b77a9a
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2017-12-26 16:39:25 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2017-12-26 16:39:56 +0000

    dev-libs/mpc: fix build failure against mpfr-4.0.0, bug #642300
    
    mprf-4.0.0 introduced new 'mpfr_fmma' symbol that collides
    with mpc's 'mpfr_fmma' symbol.
    
    It's a backport of upstream commit
    https://scm.gforge.inria.fr/anonscm/gitweb?p=mpc/mpc.git;a=commitdiff;h=36a84f43f326de14db888ba07936cc9621c23f19
    ("use mpfr_fmma and mpfr_fmms if provided by mpfr")
    which does the following to mitigate build failure:
    - rename local symbol to 'mpc_fmma' to avoid collision
    - reuse mpfr's symbol if that exists
    
    Reported-by: Perfect Gentleman
    Closes: https://bugs.gentoo.org/642300
    Package-Manager: Portage-2.3.19, Repoman-2.3.6

 dev-libs/mpc/files/mpc-1.0.3-mpfr-4.0.0.patch | 85 +++++++++++++++++++++++++++
 dev-libs/mpc/mpc-1.0.3.ebuild                 |  1 +
 2 files changed, 86 insertions(+)
Comment 8 Ben Kohler gentoo-dev 2017-12-26 18:52:09 UTC
*** Bug 642338 has been marked as a duplicate of this bug. ***
Comment 9 Attila Tóth 2017-12-26 20:50:28 UTC
I have a little bit of a problem here. After mpfr has been updated, mpc must be recompiled too. However two macros have been removed from mpfr, namely: mpfr_add_one_ulp and mpfr_sub_one_ulp. I understand, that those two macros were obsolete, but gcc is test those libraries and fails with libmpc.so undefined symbol mpfr_add_one_ulp. A user can into a nasty situation here, if doesn't have a backup. Please advise, how to avoid that.
Comment 10 Larry the Git Cow gentoo-dev 2017-12-26 20:59:19 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b7c414167ec7a2916d933d12805d869a4d4b9bd4

commit b7c414167ec7a2916d933d12805d869a4d4b9bd4
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2017-12-26 20:58:23 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2017-12-26 20:59:11 +0000

    dev-libs/mpc: revert today's changes for 1.0.3 ebuild, bug #642300
    
    This change reverts the following changes:
        commit 0c689de38bcc3b4279aa9e3b09c836e48a237e3d
        dev-libs/mpc: explicitly regenerate ./configure, noticed by Anarchy
    
        commit cdf7f5c37e8a3dfacfbf5fc81a6a2a8ef3b77a9a
        dev-libs/mpc: fix build failure against mpfr-4.0.0, bug #642300
    
    That way 1.0.3 version will keep failing to build against mpfr-4.0.0
    (and prevent users from breaking gcc) and version 1.0.3-r1 will work
    as expected.
    
    Reported-by: Attila Tóth
    Bug: https://bugs.gentoo.org/642300
    Package-Manager: Portage-2.3.19, Repoman-2.3.6

 dev-libs/mpc/mpc-1.0.3.ebuild | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)}
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2017-12-26 21:01:57 UTC
(In reply to Attila Tóth from comment #9)
> I have a little bit of a problem here. After mpfr has been updated, mpc must
> be recompiled too. However two macros have been removed from mpfr, namely:
> mpfr_add_one_ulp and mpfr_sub_one_ulp. I understand, that those two macros
> were obsolete, but gcc is test those libraries and fails with libmpc.so
> undefined symbol mpfr_add_one_ulp. A user can into a nasty situation here,
> if doesn't have a backup. Please advise, how to avoid that.

My apologies!

My "fix" was worse than original state. I've reverted all my changes to 1.0.3 ebuild to keep it build-broken against mpfr-4.0.0.

1.0.3-r1 ebuild should work fine against at least mpfr-4.0.0 and mpfr-3.1.6 versions.
Comment 12 Attila Tóth 2017-12-26 21:46:05 UTC
(In reply to Sergei Trofimovich from comment #11)
> (In reply to Attila Tóth from comment #9)
> > I have a little bit of a problem here. After mpfr has been updated, mpc must
> > be recompiled too. However two macros have been removed from mpfr, namely:
> > mpfr_add_one_ulp and mpfr_sub_one_ulp. I understand, that those two macros
> > were obsolete, but gcc is test those libraries and fails with libmpc.so
> > undefined symbol mpfr_add_one_ulp. A user can into a nasty situation here,
> > if doesn't have a backup. Please advise, how to avoid that.
> 
> My apologies!
> 
> My "fix" was worse than original state. I've reverted all my changes to
> 1.0.3 ebuild to keep it build-broken against mpfr-4.0.0.
> 
> 1.0.3-r1 ebuild should work fine against at least mpfr-4.0.0 and mpfr-3.1.6
> versions.

It's not your fault. Fortunately I have a backup.
I see, that the issue is being taken care of now:
https://bugs.gentoo.org/642316
with a critical importance.
Comment 13 Attila Tóth 2017-12-26 21:50:42 UTC
(In reply to Sergei Trofimovich from comment #11)
> (In reply to Attila Tóth from comment #9)
> My apologies!
> 
> My "fix" was worse than original state. I've reverted all my changes to
> 1.0.3 ebuild to keep it build-broken against mpfr-4.0.0.
> 
> 1.0.3-r1 ebuild should work fine against at least mpfr-4.0.0 and mpfr-3.1.6
> versions.

Oh, I've just took a look on Comment 7. I could compile the ebuild. But if the user is in an interim state of upgrading the system, that can lead to an unwanted situation hard to get out of.
Mpc and mpfr is required by gcc, so the whole upgrade must be orchestrated carefully. One problem here is that mpfr dropped mpfr_add_one_ulp and mpfr_sub_one_ulp - two macros previously present, but now became missing symbols.
Comment 14 Attila Tóth 2017-12-26 22:02:52 UTC
Created attachment 511700 [details, diff]
mpc-1.0.3-replace-obsolete-mpfr-add_sub-functions.patch

This commit seems to be important regarding this issue.
Comment 15 Attila Tóth 2017-12-26 22:08:42 UTC
Created attachment 511702 [details]
mpc-1.0.3-r1.tar.bz2

I've cherry picked some more commits from upstreams and put together a more recent instance of mpc-1.0.3. Including the commit attached separately. Might come handy for toolchain folks. It's Christmas, Theo! ;-)
I don't know why upstream hasn't released a new minor version for some time now. It would be better to stay closer to the trunk. I was also contemplating on why mpfr and mpc is not a sys-devel package, if it is that crucial for gcc...
Comment 16 Benda Xu gentoo-dev 2017-12-29 03:58:30 UTC
Is it possible to have a patch against both configure.ac and configure?

During Gentoo Prefix bootstrap, mpc is compiled before Gentoo automake (nor perl nor gcc) is available.  eautoreconf is too much a burden to bootstrap.
Comment 17 Larry the Git Cow gentoo-dev 2017-12-29 10:43:33 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66cdca4a0b121ae77b2530b080e414f96569206a

commit 66cdca4a0b121ae77b2530b080e414f96569206a
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2017-12-29 10:43:01 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2017-12-29 10:43:26 +0000

    dev-libs/mpc: remove eautoreconf call from ebuild, bug #642300
    
    As mpc is one of bootstrap libraries it's highly undesirable
    to depend on autotools. Early autotools requirement breaks
    prefix bootstrap for example. See https://bugs.gentoo.org/642300
    
    The change updates patch to modify both configure.ac and configure.
    
    Bug: https://bugs.gentoo.org/642576
    Closes: https://bugs.gentoo.org/642300
    Package-Manager: Portage-2.3.19, Repoman-2.3.6

 dev-libs/mpc/files/mpc-1.0.3-mpfr-4.0.0.patch | 44 +++++++++++++++++++++++++++
 dev-libs/mpc/mpc-1.0.3-r1.ebuild              |  3 +-
 2 files changed, 45 insertions(+), 2 deletions(-)