Created attachment 529678 [details] build.log In file included from /var/tmp/portage/dev-cpp/glibmm-2.52.1/work/glibmm-2.52.1/glib/glibmm.h:90, from /var/tmp/portage/dev-cpp/glibmm-2.52.1/work/glibmm-2.52.1/glib/glibmm/bytes.cc:4: /var/tmp/portage/dev-cpp/glibmm-2.52.1/work/glibmm-2.52.1/glib/glibmm/threads.h: In member function ‘GPrivate* Glib::Threads::Private<T>::gobj()’: /var/tmp/portage/dev-cpp/glibmm-2.52.1/work/glibmm-2.52.1/glib/glibmm/threads.h:660:29: error: cannot convert ‘GPrivate’ {aka ‘_GPrivate’} to ‘GPrivate*’ {aka ‘_GPrivate*’} in return GPrivate* gobj() { return gobject_; } ^~~~~~~~
Created attachment 529680 [details] emerge --info
I wonder why it did not fail before. Maybe gcc-8 mecame stricter about type-checking template classes. This tweak makes it compile for gcc-8: diff --git a/glib/glibmm/threads.h b/glib/glibmm/threads.h index 5350a99..cc48c01 100644 --- a/glib/glibmm/threads.h +++ b/glib/glibmm/threads.h @@ -657,7 +657,7 @@ public: */ inline void replace(T* data); - GPrivate* gobj() { return gobject_; } + GPrivate* gobj() { return &gobject_; } private: GPrivate gobject_;
Created attachment 529692 [details, diff] glibmm-2.52.1-gcc-8.patch
Thanks for the patch, it works for me. Once applied to dev-cpp/glibmm it also indirectly helps to successfully build and merge following packages: dev-cpp/atkmm dev-cpp/pangomm =dev-cpp/gtkmm-2.24.5 =dev-cpp/gtkmm-3.22.2 dev-cpp/gconfmm dev-cpp/libglademm sys-block/gparted media-sound/paprefs media-sound/pavumeter media-sound/pavucontro I guess you can avoid a lot of bugreports if you push that patch into Gentoo Portage tree.
Patch works for me too.
This has been fixed upstream [1]. What I do not understand is how come that this has never been a problem before -- that code was clearly wrong all the time. Perhaps it's some compiler-version-detection which suddenly forces that code to be compiled for the first time? Anyway, they also have a funny release process where they ship just some .hg file in git, but .h file in a tarball. One should patch both. I'll send a pull request once my rebuild-the-world-after-gcc-4.9-to-gcc-8.1 proceeds far enough to unbreak Git :). [1] https://bugzilla.gnome.org/show_bug.cgi?id=791711
*** Bug 654772 has been marked as a duplicate of this bug. ***
*** Bug 655274 has been marked as a duplicate of this bug. ***
<offtop> > rebuild-the-world-after-gcc-4.9-to-gcc-8.1 That sounds almost like "definition of having fun" :-D </offtop>
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85e6e0e04ae19670b071820947d941e521d1200e commit 85e6e0e04ae19670b071820947d941e521d1200e Author: Jan Kundrát <jkt@kde.org> AuthorDate: 2018-05-05 08:59:52 +0000 Commit: Gilles Dartiguelongue <eva@gentoo.org> CommitDate: 2018-05-22 12:17:03 +0000 dev-cpp/glibmm: Fix build with GCC 8 Patch taken from upstream and adapted to actually touch the pregenerated file shipped with the release tarbal as well. That code appears to have been always wrong, with no chance to build. This probably means that GCC 8 is suddenly being detected in some other way, making the code use that include file which was previously apparently kept unused. But anyway, upstream killed that include in a later release, so let's just let this build and watch the eventual breakage. Upstream says: > Fixed in the glibmm-2-54 branch. No fix is necessary in the master > branch. The threads.hg and threads.h files don't exist there. Closes: https://bugs.gentoo.org/654776 Bug: https://bugzilla.gnome.org/show_bug.cgi?id=791711 Closes: https://github.com/gentoo/gentoo/pull/8324 .../glibmm/files/glibmm-fix-threads-gobject.patch | 34 ++++++++++++++++++++++ dev-cpp/glibmm/glibmm-2.52.1.ebuild | 6 ++++ 2 files changed, 40 insertions(+)
This fix really should have resulted in a revision bump, and I'd still recommend a 2.52.1-r1 version of the ebuild, since I couldn't even get past the configuration of inkscape (bug #655274) until I found out about this problem and then manually remerged glibmm-2.52.1.
*** Bug 658708 has been marked as a duplicate of this bug. ***
*** Bug 661226 has been marked as a duplicate of this bug. ***
There's a "revbump" by now, in the form of a bump to 2.54.1. I'd hope that goes stable before gcc8 (but glib 2.54 is NOT a stable candidate as of yet due to python-single usage that's not solved yet with split packages; however I think glibmm-2.54 works with glib-2.52... but gcc8 stable is probably rather far away anyways)
