Summary: | sci-electronics/gnucap-0.35.20091207 : /.../stl_algobase.h:691:5: error: redefinition of ‘template<class _ForwardIterator, class _Tp> int std::__fill_a(_ForwardIterator, _ForwardIterator, const _Tp&)’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | The Soldering-Iron Brotherhood <sci-electronics> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | junk4me46806, kamikaze.is.waiting.you, mentadent47, pacho, plevine457, robink, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 614656 | ||
Bug Blocks: | 582084 | ||
Attachments: |
emerge-history.txt
environment sci-electronics:gnucap-0.35.20091207:20160918-061241.log.bz2 Fixed ebuild for 20091207 Bumped ebuild for 20130423 |
Description
Toralf Förster
2016-09-18 08:57:17 UTC
Created attachment 446352 [details]
emerge-history.txt
Created attachment 446354 [details]
environment
Created attachment 446356 [details]
sci-electronics:gnucap-0.35.20091207:20160918-061241.log.bz2
IMHO these bugs aren't worth fixing. There are a tremendous number of bugs based on the treatment of methods like std::complex<float>::real() as if they return an lvalue. AFAIK they always returned an rvalue. i.e.,
> std::complex<float> tst();
> tst.real() = 6; // Assignment to a temporary rvalue is meaningless
There are newer versions such as gnucap-2013-04-23 that should be bumped instead.
*** Bug 610616 has been marked as a duplicate of this bug. *** This issue occurred starting with gcc 6.2 and still exists with gcc 6.3. Starting with gcc 6.2 the default language standard for g++ is no longer gnu++98. The code in question is somehow correct for c++98 with gnu extensions. Adding -std=gnu++98 to CXXFLAGS fixes the issue. As for the 2013-04-23 version, it has the same issue. The models still require -std=gnu++98 to build and generate very similar errors. Created attachment 477644 [details]
Fixed ebuild for 20091207
This ebuild forces the CXXFLAG -std=gnu++98 which fixes the issue.
Created attachment 477646 [details]
Bumped ebuild for 20130423
This ebuild works with version 20130423 it forces the CXXFLAG -std=gnu++98 and includes some other changes to build and install properly.
For the record, I did try to build 20160724 as suggested by Bug 614656. I had no trouble with the base code. However, I could not build the models in the same repository: https://git.savannah.gnu.org/cgit/gnucap/gnucap-models.git/snapshot/gnucap-models-af119e0688b6c984103aca6ab544f246a5e6723b.tar.gz See Bug 614656 for details. (In reply to Peter Levine from comment #4) > IMHO these bugs aren't worth fixing. There are a tremendous number of bugs > based on the treatment of methods like std::complex<float>::real() as if > they return an lvalue. AFAIK they always returned an rvalue. i.e., > > > std::complex<float> tst(); > > tst.real() = 6; // Assignment to a temporary rvalue is meaningless > > There are newer versions such as gnucap-2013-04-23 that should be bumped > instead. Working with gnucap-0.35.20091207, I was able to patch out the problems associated with modifying rvalues. The C++11 standard explicitly sets aside the use of 'reinterpret_cast<T(&)[2]>(z)[0]' for `complex<T>` just for this very purpose. There were more errors associated with the redefinition of 'bool'. C++98 appears to have allowed redefinition of 'bool' but it is disallowed in C++11. The work necessary to omit such redefinitions and adjust every point of use for 'bool' to some other equivalent pre-C++11 meaning would be quite large. (In reply to maurerpe from comment #7) > Created attachment 477644 [details] > Fixed ebuild for 20091207 > > This ebuild forces the CXXFLAG -std=gnu++98 which fixes the issue. Normally I would caution restraint in using -std=gnu++98, as it acts as a bandage that might be more of a problem in the future if these issues are ever fixed upstream, this is a pretty good candidate for it. Gnucap's models are full of code that depend on quirks in C++98 that have been ironed out in modern C++. I don't use gnucap so I'm not sure how important the model plugins are (other distros like Debian and SUSE don't appear to install them). If they are still needed, gnucap should probably force '-std=gnu++98'. Otherwise, there shouldn't be a problem building gnucap without them. Then, I guess the only "solution" would be to try to bump to the latest one and drop models, right? (In reply to Pacho Ramos from comment #11) > Then, I guess the only "solution" would be to try to bump to the latest one > and drop models, right? You could keep the current versions and just drop models. IIRC it was the models that had the problematic code. not sure if it is the same problem but I'm unable to build this package with gcc version 6.4.0 (Gentoo 6.4.0 p1.0) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=83191499c969a0fd64a515fdba5d0a5088a36ff2 commit 83191499c969a0fd64a515fdba5d0a5088a36ff2 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2017-09-20 21:24:57 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-09-20 21:25:27 +0000 sci-electronics/gnucap: Force -std=gnu++98 to fix build with gcc-6, bug 594184 The code is otherwise rather unfixable. Maybe one day somebody will have mercy and do a version bump. Closes: https://bugs.gentoo.org/594184 Package-Manager: Portage-2.3.10, Repoman-2.3.3 sci-electronics/gnucap/gnucap-0.35.20091207.ebuild | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) |