|Summary:||[patch] Upgrade to 1.0.6 and build with C++11 support|
|Product:||[Fedora] Fedora||Reporter:||Tim Niemueller <tim>|
|Component:||mongo-cxx-driver||Assignee:||Marek Skalický <mskalick>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||22||CC:||jackyzhu2015, jwakely, mskalick|
|Fixed In Version:||mongo-cxx-driver-1.0.7-1.fc23||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-12-03 20:21:10 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Tim Niemueller 2015-10-22 13:11:47 UTC
Created attachment 1085498 [details] mongo-cxx-driver spec update based on package repo Description of problem: The current mongo-cxx-driver is built with the C++98 standard (GCC 5 default). However, recent versions of mongo-cxx-driver crash if the application and library are built with different C++ versions. We are about to upgrade Fawkes which requires C++11 and supports MongoDB, requiring this modification. There are not many dependent pacakges: # dnf repoquery --whatrequires "libmongoclient.so.1()(64bit)" Last metadata expiration check performed 0:06:17 ago on Thu Oct 22 15:00:23 2015. iwhd-0:1.6-13.fc22.x86_64 mongo-cxx-driver-devel-0:1.0.5-1.fc22.x86_64 uwsgi-plugin-gridfs-0:126.96.36.199-1.fc22.x86_64 uwsgi-plugin-gridfs-0:2.0.9-4.fc22.x86_64 uwsgi-stats-pusher-mongodb-0:188.8.131.52-1.fc22.x86_64 uwsgi-stats-pusher-mongodb-0:2.0.9-4.fc22.x86_64 uwsgi seems to require C++11 support itself (cf. https://github.com/unbit/uwsgi/blob/master/plugins/gridfs/uwsgiplugin.py). iwhd might need an upgrade, but since it is Fedora internal I suspect it is not widely used and has very supportive developers. The attached patch (on top of the mongo-cxx-driver package repo) adds the C++11 flag and along the way upgrades to 1.0.6.
Comment 1 Marek Skalický 2015-10-22 15:04:14 UTC
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?
Comment 2 Tim Niemueller 2015-10-23 06:46:52 UTC
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.
Comment 3 Marek Skalický 2015-10-23 12:46:34 UTC
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?
Comment 4 Tim Niemueller 2015-10-23 13:44:02 UTC
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.
Comment 5 Tim Niemueller 2015-10-23 13:50:32 UTC
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.
Comment 6 Marek Skalický 2015-10-26 11:05:25 UTC
(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.
Comment 7 Marek Skalický 2015-10-26 11:14:49 UTC
Link to mailing list archive: https://lists.fedoraproject.org/pipermail/devel/2015-October/216100.html
Comment 8 Tim Niemueller 2015-11-05 09:29:56 UTC
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.
Comment 9 Jonathan Wakely 2015-11-11 16:35:58 UTC
(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.
Comment 10 Tim Niemueller 2015-11-17 13:15:11 UTC
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.
Comment 11 Marek Skalický 2015-11-20 12:32:22 UTC
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...
Comment 12 Fedora Update System 2015-11-20 12:51:18 UTC
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
Comment 13 Fedora Update System 2015-11-22 14:26:23 UTC
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
Comment 14 Fedora Update System 2015-12-03 20:21:07 UTC
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.
Comment 15 Jonathan Wakely 2015-12-04 11:30:39 UTC
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"
Comment 16 Marek Skalický 2015-12-04 15:09:03 UTC
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?
Comment 17 Jonathan Wakely 2015-12-04 15:26:37 UTC
(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.