[SERVER-61305] Unable to use system provided abseil-cpp Created: 07/Nov/21 Updated: 29/Mar/22 Resolved: 29/Mar/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nehal J Wani | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Dev Platform 2021-11-15, Dev Platform 2021-11-29, Dev Platform 2022-03-21, Dev Platform 2022-04-04 |
| Participants: |
| Description |
|
This isn't new. Has been this way for quite some time. Steps to reproduce:
|
| Comments |
| Comment by Nehal J Wani [ 29/Mar/22 ] |
|
Thank you for considering it. At the very least, clients do not end up with a CLI option that is not officially supported. IMHO, that is a better state than before. |
| Comment by Andrew Morrow (Inactive) [ 29/Mar/22 ] |
|
Hi nehaljw.kkd1@gmail.com - I don't like to disappoint, but I'm sorry to say that after considerable internal debate, we have decided not only to not fix the support for building with --use-system-abseil-cpp, but to go so far as to remove that flag entirely. The next LTS release of MongoDB, 6.0, will not offer it. We do not believe that the release model for abseil is suitable for presentation as a system package that we can meaningfully consume. I understand that you may disagree with that decision. The change we made is simple enough (it is linked in this ticket) that it should be straightforward for you to fold a revert into the patch you provided earlier, should you decide that you still wish to build against the system abseil. |
| Comment by Githook User [ 28/Mar/22 ] |
|
Author: {'name': 'Andrew Morrow', 'email': 'acm@mongodb.com', 'username': 'acmorrow'}Message: |
| Comment by Andrew Morrow (Inactive) [ 09/Nov/21 ] |
|
No blog post, sorry, but I can assure you that we aren't switching build systems anytime soon. It would be an enormous undertaking for us. I do understand the reluctance to use vendored components. We will see if we can do something smarter that would make this work better. There really isn't any reason in principle that we couldn't consult pkg-config ourselves to get the library names, though of course it would require some effort. But even using the pkg-config approach assumes that the package names are stable. Has abseil committed to a stable set of package names? Meanwhile, I do have a few other pieces of information that you may find interesting:
|
| Comment by Nehal J Wani [ 09/Nov/21 ] |
|
In the conda forge ecosystem, we try very hard to not link dependencies statically, if we can avoid them. Even if upstream drops the support, I might have to patch it anyway.
If mongodb uses CMake, then abseil wouldn't have been a problem, since the targets names would come from the respective find module from the 3rd party library itself. Is there a blog post/JIRA which lists the reasons as to why Scons is so critical?
|
| Comment by Andrew Morrow (Inactive) [ 09/Nov/21 ] |
|
I started looking into this. The instability of the abseil target names probably renders this impossible to achieve in a good way, unfortunately. Without being able to know the names of the system abseil libraries that support the features we need, we simply can't declare that we depend on them in a meaningful way. As you note, you constantly need to update your patch as the abseil project iterate the names. We may need to go the other way, and just drop support for --use-system-abseil entirely. It probably isn't a good idea anyway, since as far as I know the abseil folks aren't offering any sort of ABI stability assurances, and I don't think most distributions package it. Most projects that use it seem to vendor it. How severe a limitation would it be if conda needed to stop using the flag? Meanwhile, regarding build systems: I know a bit about bazel from prior experience with it in a slightly different context, and I know CMake reasonably well from writing the build system for libmongocxx. However, we currently have no plans to move away from SCons to either of those or to anything else. We are heavily invested in SCons and it affords us a level of flexibility that is hard to achieve with others. |
| Comment by Nehal J Wani [ 07/Nov/21 ] |
|
Although it is not ideal, I've been patching my way around this for quite some time now. https://github.com/conda-forge/mongodb-feedstock/blob/master/recipe/patches/0005-Fix-flags-for-un-vendoring-abseil-cpp.patch . First, it looks ugly, second, I've to update it whenever absl changes target names, which adds to the ugliness. Are there any plans to move to a different build system? I heard somewhere that bazel was a possibility. Please don't! |