Created attachment 575566 [details] mstflint-4.11.0_p5.ebuild =sys-fabric/mstflint-4.10.0_p3 -- the ebuild revision currently in whatever people are calling gentoo-x86 these days (iow, standard gentoo rsync) -- is apparently not compatible with gcc-9.1.0; for me it does this: make[3]: Entering directory '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/work/mstflint-4.10.0-3/ext_libs/muparser' x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../.. -W -Wno-error -g -MP -MD -fPIC -Wno-deprecated-declarations -march=native -O2 -ggdb3 -pipe -DHAVE_TERMIOS_H -Werror -DMST_UL -Wno-implicit-fallthrough -Wno-format-overflow -Wno-cast-function-type -Wno-class-memaccess -c -o muParserBase.o muParserBase.cpp muParserBase.cpp: In member function ‘void mu::ParserBase::AddCallback(const string_type&, const mu::ParserCallback&, mu::funmap_type&, const char_type*)’: muParserBase.cpp:360:28: error: implicitly-declared ‘constexpr mu::ParserCallback& mu::ParserCallback::operator=(const mu::ParserCallback&)’ is deprecated [-Werror=deprecated-copy] 360 | a_Storage[a_strName] = a_Callback; | ^~~~~~~~~~ In file included from muParserToken.h:36, from muParserStack.h:35, from muParserBase.h:39, from muParserBase.cpp:26: muParserCallback.h:83:5: note: because ‘mu::ParserCallback’ has user-provided ‘mu::ParserCallback::ParserCallback(const mu::ParserCallback&)’ 83 | ParserCallback(const ParserCallback &a_Fun); | ^~~~~~~~~~~~~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:447: muParserBase.o] Error 1 make[3]: Leaving directory '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/work/mstflint-4.10.0-3/ext_libs/muparser' make[2]: *** [Makefile:400: all-recursive] Error 1 make[2]: Leaving directory '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/work/mstflint-4.10.0-3/ext_libs' make[1]: *** [Makefile:532: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/work/mstflint-4.10.0-3' make: *** [Makefile:419: all] Error 2 * ERROR: sys-fabric/mstflint-4.10.0_p3::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=sys-fabric/mstflint-4.10.0_p3::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-fabric/mstflint-4.10.0_p3::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/temp/environment'. * Working directory: '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/work/mstflint-4.10.0-3' * S: '/var/tmp/portage/sys-fabric/mstflint-4.10.0_p3/work/mstflint-4.10.0-3' Rather than try to fix the old ebuild, here's a (partially) updated ebuild for the latest pre-release revision, =sys-fabric/mstflint-4.11.0_p5. I kludged this together pretty quick and found a number of automagic and/or new dependencies looking at configure.ac. I can't say I took the time to carefully determine which dependencies (i.e., mupdf) might belong behind a useflag (i.e., doc?) -- I just shoveled them all in. Anyhow this could be a starting point if someone feels like checking my work and tidying things up a bit, or an escape-hatch for someone trying to get up and running with a gcc-9-only system.
Created attachment 575572 [details] mstflint-4.11.0_p5.ebuild updates EGIT_COMMIT constant to correct value
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=791956e26824259daab9202c57a9a815ef486c5c commit 791956e26824259daab9202c57a9a815ef486c5c Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-05-13 18:58:49 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-05-13 19:07:57 +0000 sys-fabric/mstflint: version bump to 4.11.0_p5 Bug: https://bugs.gentoo.org/685430 Package-Manager: Portage-2.3.66, Repoman-2.3.12 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-fabric/mstflint/Manifest | 1 + sys-fabric/mstflint/mstflint-4.11.0_p5.ebuild | 35 +++++++++++++++++++++++++++ 2 files changed, 36 insertions(+)
It builds for me without any of these deps that you added to the ebuild: app-arch/xz-utils:= app-text/mupdf dev-libs/boost dev-libs/expat dev-libs/iniparser dev-libs/json-c Does the ebuild that I've committed work for you?
"work" as in seem right? Or work as in actually work? Anyhow (In reply to Zac Medico from comment #3) > It builds for me without any of these deps that you added to the ebuild: > > app-arch/xz-utils:= > app-text/mupdf > dev-libs/boost > dev-libs/expat > dev-libs/iniparser > dev-libs/json-c > > Does the ebuild that I've committed work for you? Work as in "feel right"? Or as in function? If the former.... ok, most of those dependencies are optionally vendored with automagic reversion to system-deps, if detected by configure. So I guess my thinking was we get a more gentoo-ly correct deployment. But, OTOH, if one did happen to already have those things installed, they got dynamic linking etc, so who is the victim? The only downside is the untracked dependency between packages but, let's face it, this is common, nobody really notices. If "work". Yep. Although I'm really surprised this thing builds without boost if it consumes it. I wonder if maybe the boost-depending portions get excluded from the package? Or are part of the doc generation? I'd say just leave it and if someone wants to fix any subtle correctness/completeness issues, let them open a new bug.
(In reply to Greg Turner from comment #4) > "work" as in seem right? Or work as in actually work? Anyhow (In reply to > Zac Medico from comment #3) > > It builds for me without any of these deps that you added to the ebuild: > > > > app-arch/xz-utils:= > > app-text/mupdf > > dev-libs/boost > > dev-libs/expat > > dev-libs/iniparser > > dev-libs/json-c > > > > Does the ebuild that I've committed work for you? > > Work as in "feel right"? Or as in function? If the former.... ok, most of > those dependencies are optionally vendored with automagic reversion to > system-deps, if detected by configure. > > So I guess my thinking was we get a more gentoo-ly correct deployment. But, > OTOH, if one did happen to already have those things installed, they got > dynamic linking etc, so who is the victim? The only downside is the > untracked dependency between packages but, let's face it, this is common, > nobody really notices. Yeah, it's probably not worth the trouble if nobody notices. > If "work". Yep. Although I'm really surprised this thing builds without > boost if it consumes it. I wonder if maybe the boost-depending portions get > excluded from the package? Or are part of the doc generation? Hmm, that's a good question. For testing, I did unmerge both boost and boost-build. > I'd say just leave it and if someone wants to fix any subtle > correctness/completeness issues, let them open a new bug. Sounds good. Thanks!
