Bug 1274307

Thank you Tim for that patch, I will add it to the Fedora tomorrow.

However, which are you targeting?
With Rawhide there could be no problem. F22 is too old in my point of view. F23? - there MongoDB is also build with c++11, nevertheless packages you have mentioned should be rebuild for f23 too. Do you think it is possible?

I would definitely think so. I'm also strongly in favor of upgrading F22. We are using it as our current base for development and running robots (we usually follow the even numbered releases to lower the upgrade burden). I think since it is such a low number of packages with low impact this is feasible. I assume that some probably would even crash, if someone were to use the MongoDB features at this point. An Boost-internal exception seems to be certain if the wrong C++ standard version is used (cf. https://jira.mongodb.org/browse/CXX-717).

I would give the other packages' owners a heads-up and coordinate a joint update.

Fedora 23 is going to be released in 4 days. So F22 won't be the latest release so I think so "big" change shouldn't be made there (especially that other packages have to be rebuild too).
In F23 maybe, but it could be hard to coordinate this with other packages.

In my point of view the best solution could be to enable c++11 in Rawhide and to create COPR repository with mongo-cxx-driver with c++11 and packages mentioned in #c1
What do you think about this?

Thing is that it is not a big change and things are most likely currently broken in the uwsgi case anyway. So I'd rather have it fixed properly once, even though it not the latest release, it's still a supported one.

I had a brief look at iwhd. The project has not received commits in years (https://git.fedorahosted.org/git/iwhd.git). Additionally, it is for example lacking a call to mongo::client::initialize(), which essentially means it will not work.

Since convinces me even more that we should fix this now in F22 an upwards. In its current state it is of no use, neither to the dependent packages which seem to have essentially been abandoned and collect dust nor to someone who wants to use it as a build dependency with a modern C++ version.

Therefore, I kindly ask to go ahead and update mongo-cxx-driver, inform the iwhd maintainers that there package is most likely broken *already* and uwsgi that they will need to issue a rebuild.

Just to add: I have given iwhd a try and it indeed segfaults. Run "strace -f iwhd  --verbose -a" and you see threads crashing on and on. My guess is that this is exactly due to the uninitialized mongo-cxx-driver.

(In reply to Tim Niemueller from comment #4)
> Thing is that it is not a big change and things are most likely currently
> broken in the uwsgi case anyway. So I'd rather have it fixed properly once,
> even though it not the latest release, it's still a supported one.

Supported yes, however:
"All other updates MUST either:
    reach the criteria laid out in the previous section OR
    reach the positive Bodhi karma threshold specified by the updates submitter OR
    spend some minimum amount of time in updates-testing, currently one week 

Package maintainers MUST:
    Avoid Major version updates, ABI breakage or API changes if at all possible.
    Avoid changing the user experience if at all possible.
    Avoid updates that are trivial or don't affect any Fedora users. 
" (https://fedoraproject.org/wiki/Updates_Policy)

And I am afraid that this will cause an ABI breakage. That is the only think why I am not for this change in F22 and in F23 quite too.

> 
> I had a brief look at iwhd. The project has not received commits in years
> (https://git.fedorahosted.org/git/iwhd.git). Additionally, it is for example
> lacking a call to mongo::client::initialize(), which essentially means it
> will not work.
> 
> Since convinces me even more that we should fix this now in F22 an upwards.

Sorry, but this fix in mongo-cxx-driver does not fix the lack of mongo::client::initialize() in iwhd!

> In its current state it is of no use, neither to the dependent packages
> which seem to have essentially been abandoned and collect dust nor to
> someone who wants to use it as a build dependency with a modern C++ version.

C++11 ABI is default in Fedora gcc since F23...

> 
> Therefore, I kindly ask to go ahead and update mongo-cxx-driver, inform the
> iwhd maintainers that there package is most likely broken *already* and
> uwsgi that they will need to issue a rebuild.

However this is not only about packages in Fedora. Someone can use the Fedora 22 and develop there some application using mongo-cxx-driver and run it there. He is supposing driver is not using c++11. And now, half year after F22 release we change it and this may break his stuff.

So I am against enabling c++ in F22. But to have also another's opinion, I will ask on fedora-devel list.

Link to mailing list archive:
https://lists.fedoraproject.org/pipermail/devel/2015-October/216100.html

Hi Marek.

We cooked it some time on the devel list and there were no objections. Therefore, I'd like to ask to proceed with the upgrade as proposed.

(In reply to Marek Skalický from comment #6)
> C++11 ABI is default in Fedora gcc since F23...

As pointed out on the mailing list you are confusing the -std=c++XX option which sets the dialect and the libstdc++ ABI. Using -std does not change the libstdc++ ABI.

There is no "C++11 ABI". There is the cxx11 ABI, available since GCC 5.1, but that is orthogonal to any -std option.

Hi.

I have since upgrade to F23. The problem remains. The package must be ugpraded and built with the -std=c++11 flag, or anything linking against mongo-cxx-driver using the flag will crash, even without using the library (but still linking t oit) as a static initializer already crashes the library.

I have rebuilt the package with the same patch on F23 and it works. Therefore, can we please fix the package at least in F23 and rebuilt it with the patch? Thanks!

From my side we can leave the earlier versions broken as we decided to skip F22 and directly upgrade to F23.

OK, I've done a build for Rawhide and F23. F23 upgrade will be there  soon, so you can add karma...

And we will see, if some bug appears...

mongo-cxx-driver-1.0.7-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-c4c7f915ed

mongo-cxx-driver-1.0.7-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update mongo-cxx-driver'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-c4c7f915ed

mongo-cxx-driver-1.0.7-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

I'd still really like to know why (or even just where) this crashes, mixing -std=c++98 and -std=c++11 is supposed to be supported.

Has anyone even tried to debug this? I see no attempt to do so at https://jira.mongodb.org/browse/CXX-717 only "it crashes, let's change things"

According this page https://gcc.gnu.org/wiki/Cxx11AbiCompatibility for some versions of gcc there were some incompatibilities. Maybe this could be a problem... However I'm really not a well-informed in c++ standards compatibility.

Tim, do you know what could be a reason of this crash?

(In reply to Marek Skalický from comment #16)
> According this page https://gcc.gnu.org/wiki/Cxx11AbiCompatibility for some
> versions of gcc there were some incompatibilities.

Yes I know, I wrote parts of that page :-)

Most of the things listed there do not apply to the GCC version in Fedora, or only happen in unusual situations, and would only lead to some unexpected results, *not* a crash. That's why I want to know what the problem is, and if necessary fix it in GCC or update the wiki page if there is something missing.