Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 566328 (libsigc++-2.6) - [TRACKER] dev-libs/libsigc++-2.6 breakage
Summary: [TRACKER] dev-libs/libsigc++-2.6 breakage
Status: RESOLVED OBSOLETE
Alias: libsigc++-2.6
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL: http://www.murrayc.com/permalink/2015...
Whiteboard:
Keywords: Tracker
Depends on: 550764 565342 566078 566318 566450 566456 566506 566584 566586 566594 566668 566694 566910 567092 567174 567216 567498 567526 568024 568130 568136 568254 568300 568580 568590 568592 568788 568792 568794 568796 569142 569156 569508 569512 569514 569520 569528 569530 569538 569540 569606 569628 569700 569728 570218 570418 570618 570942 573476 573498 573516
Blocks: c++11-abi gnome-3.18
  Show dependency tree
 
Reported: 2015-11-20 11:55 UTC by Pacho Ramos
Modified: 2017-10-02 22:10 UTC (History)
12 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2015-11-20 11:55:07 UTC
It looks like libsigc++-2.6 need reverse deps to use -std=c++11

The rest of distributions are simply appending that flags to the packages
Comment 1 Justin Lecher gentoo-dev 2015-11-24 11:54:16 UTC
Could we get a standard snipplet?

Is this what you are thinking off?

+	if has_version \>=dev-libs/libsigc++-2.6 ; then
+		append-cxxflags -std=c++11
+	fi
Comment 2 Pacho Ramos gentoo-dev 2015-11-24 12:10:31 UTC
Would it cause issues to append it always instead of with the conditional? (that is the road other distros chose... but maybe because they only care about the latest version) Also, I wonder if maybe some package depending on glibmm but not on libsigc++ would also exhibit the issue and then would need to use a different snipped
Comment 3 Pacho Ramos gentoo-dev 2015-11-24 12:56:31 UTC
Also looks like Fedora and Ubuntu, after starting to apply this changes, simnply moved to gcc5 widely that uses -std=c++11 by default
https://lists.ubuntu.com/archives/ubuntu-devel/2015-July/038825.html

On the other hand, Debian opted for patching their glibmm to append the flag via pkgconfig files:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800371
https://bugzilla.gnome.org/show_bug.cgi?id=755750

Maybe we could try the Debian approach as I am unknown when will we be ready for gcc5
Comment 4 Pacho Ramos gentoo-dev 2015-11-25 09:25:38 UTC
@toolchain, what gcc version will start to default to -std=c++11? Maybe we should simply decrease the keywording of dev-libs/libsigc++-2.6 to the same level as that gcc version and try to keyword/stabilize it when that gcc version is ready to be stabilized

The affected packages would be:
>=dev-libs/libsigc++-2.6
>=dev-cpp/cairomm-1.12
>=dev-cpp/glibmm-2.46
>=dev-cpp/gtkmm-3.18
>=dev-cpp/pangomm-2.38
>=dev-cpp/atkmm-2.24
>=dev-cpp/gtksourceviewmm-3.18

The only issue I see is that, if having a gcc with -std=c++11 enabled will take a long time, we could start to have problems of new reverse deps needing to lose keywords with it and we would also miss the opportunity of fixing the reverse deps to be compatible with libsigc++-2.6 :/
Comment 5 Ryan Hill (RETIRED) gentoo-dev 2015-11-26 23:39:30 UTC
5.1.  Don't mess around waiting for GCC versions to go stable.  The GCC version in stable has no bearing on what GCC version people are using.   Just use -std=c++11.
Comment 6 Pacho Ramos gentoo-dev 2015-11-27 11:42:00 UTC
@jlec, then, I don't mind using either the "unconditional" way or the other. If other people from gnome team doesn't have any concern, feel free to go ahead and thanks a lot for your help (this days it will be difficult to me for committing things :S)

Thanks a lot
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-11-29 08:42:45 UTC
This is never this simple. C++11 can change the ABI. So the point kinda is, we need to ensure that all C++ libraries in a depgraph use the same C++ version.
Comment 8 Greg Turner 2015-11-30 03:38:46 UTC
(In reply to Michał Górny from comment #7)
> This is never this simple. C++11 can change the ABI. So the point kinda is,
> we need to ensure that all C++ libraries in a depgraph use the same C++
> version.

This is pretty awful when you really think about it.  I feel like I'm watching a train-wreck in super slow motion.

I'm not sure we're taking this seriously enough -- sooner or later it seems destined to become a major clusterfuck if we don't do something proactive about it now while the drawing-board is relatively uncluttered.

The only thing I can think of that has this kind of two-way depgraph magic property are the major "abi" USE_EXPAND values (multilib-build and python-r1, in other words).

But those rely on fancy framework-generated USE-flag deps, which seem like overkill and likely to incur unjustifiable user-experience-costs.

Perhaps a solution to this cxx11 clusterfuck can be found that works more like perl?  By that I mean, pick your poison (respectively, your cxx11 ABI of preference or your major perl version of choice), rely on inbuilt portage features do the trick most of the time, and, when it breaks, run "magically-fix-everything.sh," grab a caffeinated beverage or three and fire up your favorite VOD client while the mess gets magically cleaned up by robots somehow.
Comment 9 Oleh 2015-11-30 08:51:17 UTC
(In reply to Gregory Turner from comment #8)
> (In reply to Michał Górny from comment #7)
> > This is never this simple. C++11 can change the ABI. So the point kinda is,
> > we need to ensure that all C++ libraries in a depgraph use the same C++
> > version.
> 
> This is pretty awful when you really think about it.  I feel like I'm
> watching a train-wreck in super slow motion.
> 
> I'm not sure we're taking this seriously enough -- sooner or later it seems
> destined to become a major clusterfuck if we don't do something proactive
> about it now while the drawing-board is relatively uncluttered.
> 
> The only thing I can think of that has this kind of two-way depgraph magic
> property are the major "abi" USE_EXPAND values (multilib-build and
> python-r1, in other words).
> 
> But those rely on fancy framework-generated USE-flag deps, which seem like
> overkill and likely to incur unjustifiable user-experience-costs.
> 
> Perhaps a solution to this cxx11 clusterfuck can be found that works more
> like perl?  By that I mean, pick your poison (respectively, your cxx11 ABI
> of preference or your major perl version of choice), rely on inbuilt portage
> features do the trick most of the time, and, when it breaks, run
> "magically-fix-everything.sh," grab a caffeinated beverage or three and fire
> up your favorite VOD client while the mess gets magically cleaned up by
> robots somehow.

"proactive" is something gentoo never do. This is quite serious problem, and again, libsigc++ bumped, just of a matter of gnome-3.18 (cairomm) requirement without taking in acccount all reverse dependencies, and https://bugs.gentoo.org/show_bug.cgi?id=542482 (which has no good attacking plans to date). Now, "9 circles of hell" is what expected and "reactive" fixes. What should have happened, is NO gnome-3.18 updates, but it seems gentoo gnome never test systems outside of "gnome environment" But ok, stopping ranting --Matthew 7:6
Comment 10 Gilles Dartiguelongue gentoo-dev 2015-11-30 22:05:04 UTC
Come on guys, this c++11 mess has been predicted for over a year already (as first reports came in from webkit-gtk, etc), just check the gentoo-dev archives and bugzilla. Yes the current situation sucks, no this is not the fault of the Gnome team, yes, sane and constructive discussion can go a long way and this is best directed to gentoo-dev mailing list for reviews and larger panel of c++ knowledgeable devs.
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-12-01 07:03:54 UTC
Exactly. And over that time, all discussions ended up with no good solution. Therefore, I don't think this one's going to be any better and I'd rather focus on fixing the existing breakage with the tools we have.

Though it's your fault for keeping this known breakage unmasked for quite a while.

It's rather clear that sigc++ revdeps need to enable some dialect of C++11. The question is whether to:

A. Enable it independently of sigc++ version, or

B. Enable it based on installed sigc++ version.

I think A won't hurt much more and would be easier to do. But before you become lazy: don't append -std to pkg-config. Aside to it being non-portable, some packages may actually need gnu++11.
Comment 12 Pacho Ramos gentoo-dev 2015-12-01 11:23:33 UTC
Yes, the downsides of appending the flags in .pc files are a bit explained in upstream bug report

Then, I think we mostly agree on using "append-cxxflags -std=c++11" when possible and I would vote for making it unconditionally but if you prefer to make it conditional, I don't have any strong opinion against that

Regarding the fault about not keeping it masked forever, in this case it was simply missed because of the way of bumping with apps at first and later libs to try to see if upstreamed forgot to update configure.ac version checks when bumping :/

Anyway, looking to other existing breakages in the tree (like boost, samba, apache...) looks like keeping things hardmasked or not bumped only help to delay things even more (sometimes years)
Comment 13 Pacho Ramos gentoo-dev 2015-12-01 11:25:14 UTC
(In reply to Pacho Ramos from comment #4)
> The affected packages would be:
> >=dev-libs/libsigc++-2.6
> >=dev-cpp/cairomm-1.12
> >=dev-cpp/glibmm-2.46
> >=dev-cpp/gtkmm-3.18
> >=dev-cpp/pangomm-2.38
> >=dev-cpp/atkmm-2.24
> >=dev-cpp/gtksourceviewmm-3.18

@toralf, would you mind in helping us running a "stable" tinderbox with this packages keyworded to try to catch all the reverse deps that need to be fixed?

Thanks a lot
Comment 14 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-12-01 11:51:57 UTC
Well, one more problem I see is adding c++11 checks everywhere. But maybe it's time to stop doing that and just let things fail the usual way.
Comment 15 Anthony Basile gentoo-dev 2015-12-01 11:53:43 UTC
(In reply to Pacho Ramos from comment #12)
> Yes, the downsides of appending the flags in .pc files are a bit explained
> in upstream bug report
> 
> Then, I think we mostly agree on using "append-cxxflags -std=c++11" when
> possible and I would vote for making it unconditionally but if you prefer to
> make it conditional, I don't have any strong opinion against that

This may get you into trouble since there is a depth to the linkage graph and you may need to push the -std=c++11 down further than just the immediate package.  I can't be sure, this *may* work, but there is the distinct possibility that you'll get into trouble if this library further links against other libraries compiled with c++98 (ie the default for gcc-4.x).

I'll be tinderboxing for what breaks if we add CXXFLAGS="-std=c++11" globally.  I know there are problems with this approach, eg some packages might need gnu++11, but I think that fixing gnu++11 <=> c++11 incompatibility on a per package basis will be easier than fixing c++11 <=> c++98 incompatibilites.

[There is still the other problem of c++11 <=> c++11 incompatibility when switching between versions of gcc-4.x/5.y but let's deal with that separately.  There I'm going to propose an -Wl,-rpath= solution.]

@pacho, if you are available sometime next week on irc, maybe you wan walk me through what profiles/pkgs need to be tested.  I'll be using https://wiki.gentoo.org/wiki/Project:RelEng_GRS.

> 
> Regarding the fault about not keeping it masked forever, in this case it was
> simply missed because of the way of bumping with apps at first and later
> libs to try to see if upstreamed forgot to update configure.ac version
> checks when bumping :/
> 
> Anyway, looking to other existing breakages in the tree (like boost, samba,
> apache...) looks like keeping things hardmasked or not bumped only help to
> delay things even more (sometimes years)

Yeah, this was going to hit us sooner or later.  I sent out a news item for it, so did vapier.  We just don't have good solutions in Gentoo because ${choice}.  If we forced the version of gcc and the c++ abi then this problem would not exist.
Comment 16 Anthony Basile gentoo-dev 2015-12-01 12:00:06 UTC
(In reply to Ryan Hill from comment #5)
> 5.1.  Don't mess around waiting for GCC versions to go stable.  The GCC
> version in stable has no bearing on what GCC version people are using.  
> Just use -std=c++11.

@Ryan, what do you think about just pushing out CXXFLAGS+="-std=c++11" globally?  My understanding is that syntactially/semantically c++98 is a proper subset of c++11.  It should work.

If you think that's a good idea, what would be the best way of doing so?  Via the profile make.defaults?  Or gcc specs?
Comment 17 Pacho Ramos gentoo-dev 2015-12-01 12:31:24 UTC
(In reply to Anthony Basile from comment #15)
> (In reply to Pacho Ramos from comment #12)
> > Yes, the downsides of appending the flags in .pc files are a bit explained
> > in upstream bug report
> > 
> > Then, I think we mostly agree on using "append-cxxflags -std=c++11" when
> > possible and I would vote for making it unconditionally but if you prefer to
> > make it conditional, I don't have any strong opinion against that
> 
> This may get you into trouble since there is a depth to the linkage graph
> and you may need to push the -std=c++11 down further than just the immediate
> package.  I can't be sure, this *may* work, but there is the distinct
> possibility that you'll get into trouble if this library further links
> against other libraries compiled with c++98 (ie the default for gcc-4.x).
> 
> I'll be tinderboxing for what breaks if we add CXXFLAGS="-std=c++11"
> globally.  I know there are problems with this approach, eg some packages
> might need gnu++11, but I think that fixing gnu++11 <=> c++11
> incompatibility on a per package basis will be easier than fixing c++11 <=>
> c++98 incompatibilites.
> 
> [There is still the other problem of c++11 <=> c++11 incompatibility when
> switching between versions of gcc-4.x/5.y but let's deal with that
> separately.  There I'm going to propose an -Wl,-rpath= solution.]
> 
> @pacho, if you are available sometime next week on irc, maybe you wan walk
> me through what profiles/pkgs need to be tested.  I'll be using
> https://wiki.gentoo.org/wiki/Project:RelEng_GRS.

Well, I don't plan to enable -std=c++11 globally, only for the applications using the mm libs, then, I doubt the breakage will extent to many more packages once the first "round" of failing reverse deps is fixed to append the flag (this is what was done in other distributions until they moved to gcc5... I am really unsure about how safe would be to enable -std=c++11 globally for gcc49 :/)

Well, on that distributions (at least Ubuntu) maybe they took advantage of this for also moving to gcc5 as an opportunity to rebuild everything and also cope with the ABI break between gcc49 and gcc5... but I guess we won't be able to do that :|
Comment 18 Pacho Ramos gentoo-dev 2015-12-01 12:34:07 UTC
Also, I guess the problem of appending it globally would be the same as appending it with .pc files:
https://bugzilla.gnome.org/show_bug.cgi?id=755750#c4

I am unsure if we even have one package that would hit that problem... but maybe it's a bit risky :/
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-12-01 17:38:41 UTC
That's a wrong way forward. We simply shouldn't do that.
Comment 20 Toralf Förster gentoo-dev 2015-12-01 18:19:33 UTC
(In reply to Pacho Ramos from comment #13)
> @toralf, would you mind in helping us running a "stable" tinderbox with this
> packages keyworded to try to catch all the reverse deps that need to be
> fixed?
started : amd64-desktop-stable_20151201-184322

had to unmask few dep/blocker too :

>=dev-libs/glib-2.46.2
>=dev-util/gdbus-codegen-2.44.1
>=x11-libs/gtk+-3.18.5
>=dev-libs/glib-2.46.2
>=x11-libs/pango-1.38.1
>=x11-libs/libXrandr-1.5.0
>=x11-proto/randrproto-1.5.0
>=x11-libs/gtksourceview-3.18.1
>=dev-libs/atk-2.18.0
Comment 21 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-12-01 21:39:11 UTC
One more note: since this is something upstream-enforced, I'd expect revdeps to slowly adapt C++11 in their buildsystems. Therefore, we should really track that and remove our hacks once upstream solves that.
Comment 22 Anthony Basile gentoo-dev 2015-12-01 22:15:13 UTC
(In reply to Michał Górny from comment #21)
> One more note: since this is something upstream-enforced, I'd expect revdeps
> to slowly adapt C++11 in their buildsystems. Therefore, we should really
> track that and remove our hacks once upstream solves that.

Don't get me wrong, if you can track all these revdeps down and contain them, then adding -std=c++11 on a per package basis is better than turning on c++11 globally.  I'm still not sure what breaks if we do.  I know the theory, but what happens in practice.
Comment 23 Ryan Hill (RETIRED) gentoo-dev 2015-12-02 00:38:34 UTC
I believe there would be more packages broken by forcing -std=c++11 globally than there would be handling this on a per-package basis.  We also have users that rely on compilers that don't support c++11 (pre 4.7 I think).  I also would not want the standard changing in an already stable compiler series, meaning it doesn't really help us _right now_.

I actually don't mind the .pc file thing, but I'm lazy.  Up to you guys. :D

It's probably more sensible to just fix things as they break.  It'll be painful but it's the best option we have.  As Michał points out, downstreams are going to have to fix their packages eventually.  So just treat it like any other library breakage, and just hope we don't run into any abi conflicts.
Comment 24 Pacho Ramos gentoo-dev 2015-12-02 10:23:20 UTC
OK, then, I think we mostly agree on appending:
append-cxxflags -std=c++11

on broken apps. I would append it unconditionally as the upstream macro does (the upstream macro appends it as soon as a compiler with -std=c++11 support is available, as it's required now, and dies otherwise without checking for libsigc++/glibmm versions)
https://git.gnome.org/browse/mm-common/commit/?id=0cb42dc92a380b2033f92bb7f31fc8a0dc0b278a
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html
Comment 25 Pacho Ramos gentoo-dev 2015-12-02 11:53:19 UTC
(As a side note: Mageia is currently having gcc49 still, not like other major distributions that moved to gcc5 "hiding" this issue, and, then, you can also take a look to their .spec files to see how they solved the build issues for each package in the case you get further problems)
https://svnweb.mageia.org/packages/cauldron/
Comment 26 Matt Whitlock 2015-12-15 18:10:23 UTC
I'll point out that no version of GCC will ever default to -std=c++11. Rather, the default is -std=gnu++11, which is what we ought to be discussing here. Specifying -std=c++11 actually disables certain GNU extensions that are enabled by default. This would cause breakage in projects that rely on those extensions.

Also, I'll argue that globally switching to -std=gnu++11 (or -std=c++11) is a bad idea because C++11 adds new keywords to the language, which could cause syntax errors in older code that uses those keywords as identifiers.
Comment 27 SpanKY gentoo-dev 2015-12-15 19:27:16 UTC
attempting to apply any -std at a global level doesn't make sense imo and leads to way more pain than it actually fixes

btw, gcc-5.3 is in ~arch now
Comment 28 Harris Landgarten 2015-12-18 19:50:32 UTC
add mangler to the list same errors
Comment 29 Attila Tóth 2015-12-20 22:59:30 UTC
Debian folks analysis results:
https://bugzilla.gnome.org/show_bug.cgi?id=755750#c9
Summary
-------
10 packages don't use pkg-config
6 packages include sigc++/object.h
2 packages include sigc++/class_slot.h
1 package uses the deleted sigc::is_base_and_derived<> class
1 package overrides -std=c++11 by adding the -ansi compiler option
1 package uses pkg-config when a C file is compiled, and then -std=c++11 is
  illegal
5 packages contain code which is illegal in C++11, but legal in older C++
3 packages (possibly more) contain code which has become ambiguous as a result
  of more functions and classes being available in C++11

I know it's different from Gentoo...
Comment 30 Pacho Ramos gentoo-dev 2015-12-25 16:19:54 UTC
(In reply to Pacho Ramos from comment #4)
>The affected packages would be:
> >=dev-libs/libsigc++-2.6
> >=dev-cpp/cairomm-1.12
> >=dev-cpp/glibmm-2.46
> >=dev-cpp/gtkmm-3.18
> >=dev-cpp/pangomm-2.38
> >=dev-cpp/atkmm-2.24
> >=dev-cpp/gtksourceviewmm-3.18
> 

I have ended on rebuilding all reverse deps of that packages, I tried to solve as much as I was able to but the remaining blockers here are harder to handle :S 

Any help with them will be highly appreciated
Comment 31 Jocelyn Mayer 2016-06-02 08:32:32 UTC
I confirm the issue, had to add -std=c++11 flag to CXXFLAGS for those packages in order to re-merge them on a PPC G4 machine.
dev-cpp/libglademm and dev-cpp/gconfmm packages are also affected by this issue.
Comment 32 Andreas K. Hüttel gentoo-dev 2017-10-02 22:10:28 UTC
OK I guess we can close this as obsolete now. Also gcc-6 will go stable soon.