Description of problem: odb prevents gcc toolchain to be upgraded to 6.3.1 Version-Release number of selected component (if applicable): odb 2.4.0 How reproducible: Steps to Reproduce: 1.sudo dnf --best --allowerasing upgrade Actual results: [sudo] password for xxxxx: Fedora 25 - x86_64 - Updates 1.4 MB/s | 14 MB 00:09 Last metadata expiration check: 0:00:08 ago on Wed Dec 28 11:07:23 2016. Error: package odb-2.4.0-15.fc25.x86_64 requires gcc = 6.2.1, but none of the providers can be installed Expected results: gcc toolchain should be upgradable Additional info: Similar problem as old Bug 1379046. I use the usual workaround to rebuild odb from the source RPM's.
odb-2.4.0-17.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9a953557c6
odb-2.4.0-17.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-cc775ccb82
odb-2.4.0-17.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9a953557c6
odb-2.4.0-17.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-cc775ccb82
Update works.
Works, but have a question. Isn't the C++ ABI forward compatible? Why require a rebuild of the package on every GCC update?
I th(In reply to Vasco Rodrigues from comment #6) > Works, but have a question. > > Isn't the C++ ABI forward compatible? > Why require a rebuild of the package on every GCC update? I think that this was added by upstream a while back ( http://www.codesynthesis.com/pipermail/odb-users/2013-March/001115.html ). If there's a way to turn this off or make it less annoying, then I'm fine with doing that.
As I understand it, odb uses GCC "internals" to some extend and requires a certain level of compatibility. However, I think the package should seamless continue to work with "minor" updates such as 6.2.x or even 6.y.x. I'm not qualified enough to state if 6.y.x would be fine. AFAIK, GCC now increases the major version number faster than previously when doing major changes on the internals or defaults (e.g. uses g++14 as standard level) and so it is very likely to work as I've seen it since I'm using the package on fedora and got the issue with every update of GCC 6. So, could the package check for 6.x.y or at least 6.2.x to relieve this pain? I think that xsdcxx, which uses similar approaches is less a pain in the upgrades. Although I stopped using it as I noticed that it doesn't bring me any productivity increase and sometimes it is the opposite but explodes the code size of my applications.
> As I understand it, odb uses GCC "internals" to some extend and requires a certain level of compatibility. A GCC plugin that wants to do anything remotely useful will depend on GCC internals (e.g., AST). This is how things are. > However, I think the package should seamless continue to work with "minor" updates such as 6.2.x or even 6.y.x. At least on my Ubuntu GCC seems to agree with your assessment: $g++-6 -print-file-name=plugin /usr/lib/gcc/x86_64-linux-gnu/6/plugin Since the plugin installation directory is just 6 and not 6.2 or 6.2.0, then one can reasonably assume plugins are compatible across 6.X.Y. Whether it will actually work is another questions, but I think it is worth a try. > I think that xsdcxx, which uses similar approaches is less a pain in the upgrades. No, there are no GCC plugins involved there.
(In reply to Boris Kolpackov from comment #9) > > As I understand it, odb uses GCC "internals" to some extend and requires a certain level of compatibility. > > A GCC plugin that wants to do anything remotely useful will depend on GCC > internals (e.g., AST). This is how things are. Requiring the specific version of gcc was added 2.5 years ago when gcc version numbers were a completely different beast ( http://pkgs.fedoraproject.org/cgit/rpms/odb.git/commit/?id=c94e3c2e62962ea84f0feccbae5d59e72f031674 ). Maybe manually requiring the specific version of gcc has outlived its usefulness. > > However, I think the package should seamless continue to work with "minor" updates such as 6.2.x or even 6.y.x. > > At least on my Ubuntu GCC seems to agree with your assessment: > > $g++-6 -print-file-name=plugin > /usr/lib/gcc/x86_64-linux-gnu/6/plugin > > Since the plugin installation directory is just 6 and not 6.2 or 6.2.0, then > one can reasonably assume plugins are compatible across 6.X.Y. Whether it > will actually work is another questions, but I think it is worth a try. The plugin is still being installed into a path with the full version: https://koji.fedoraproject.org/koji/rpminfo?rpmID=8787600
> Maybe manually requiring the specific version of gcc has outlived its usefulness. You still would want to require the specific major version. I think through painful experience we have established that those are definitely incompatible ;-). > The plugin is still being installed into a path with the full version > > /usr/lib/gcc/x86_64-redhat-linux/6.3.1/plugin/odb.so Ok, so it looks like Fedora (unlike Ubuntu and probably Debian) believes plugins are incompatible. Maybe it makes sense to ask on the relevant list why there is such a belief?
Wouldn't be wise to check with the upstream odb authors how things stand today with the new versioning approach of GCC? The current state of affairs on Fedora is really a pain, as I've been through 3 times the same issue in less than a year. This adds a reason for me to look at alternatives to have c++ multidb sql support and have some hopes on projects like sqlpp11 or cppstddb. These offer a better control on how the updates are performed on the db but at the cost of "transparency". But this is off topic to the issue at hand.
(In reply to Serge Robyns from comment #12) > Wouldn't be wise to check with the upstream odb authors how things stand > today with the new versioning approach of GCC? The current state of affairs > on Fedora is really a pain, as I've been through 3 times the same issue in > less than a year. Boris is the upstream author of odb. > This adds a reason for me to look at alternatives to have c++ multidb sql > support and have some hopes on projects like sqlpp11 or cppstddb. These > offer a better control on how the updates are performed on the db but at the > cost of "transparency". But this is off topic to the issue at hand. I no longer use odb as an C++ ORM solution and I've just been maintaining to be nice. I'm definitely open to minimize the pain to users and the amount of work I have to do, but it sounds like this is an issue with how Fedora defines the plugin directory for gcc and not something I can directly fix.
I understand. Maybe Fedora expects package owners to be very "reactive" and adjust their packages prior releasing GCC updates. Thanks for continue to maintain the package as you do.
> Wouldn't be wise to check with the upstream odb authors how things stand today with the new versioning approach of GCC? The current state of affairs on Fedora is really a pain, as I've been through 3 times the same issue in less than a year. Yes, distribution packaging situation is getting worse. Dave is still doing an excellent job: in Ubuntu LTS we have libodb* runtimes broken (built with different versions of GCC), there is a bug report open for months, and nobody cares. Our long term solution for this is build2: https://build2.org > But this is off topic to the issue at hand. Right. Plus, making thinly veiled threat to switch to another project will hardly help your cause. > [...] it sounds like this is an issue with how Fedora defines the plugin directory for gcc and not something I can directly fix. One way to sidestep this whole issue would be to somehow trigger a package rebuild every time there is a GCC version update. Not sure if it's possible/easy to automate.
(In reply to Serge Robyns from comment #14) > I understand. Maybe Fedora expects package owners to be very "reactive" and > adjust their packages prior releasing GCC updates. > Thanks for continue to maintain the package as you do. The problem is that the rebuild has to be done after the gcc update is pushed to stable or using a buildroot override (which is a big pain). I opened bug 1410498 to request that the path be fixed.
odb-2.4.0-17.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
odb-2.4.0-17.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.