[CXX-172] on linux systems it is customary to use sonames when creating shared libraries Created: 14/Oct/10  Updated: 27/May/22  Resolved: 07/Jan/15

Status: Closed
Project: C++ Driver
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Ian Whalen (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 2
Labels: build, cxxmove, legacy-cxx
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-6514 scons --sharedclient mongoclient buil... Closed
Duplicate
is duplicated by SERVER-3558 C++ driver libraries doesn't have a s... Closed
Related
is related to CXX-42 Create a C++ driver redistributable p... Closed
Server Compat: 2.4, 2.5

 Description   

I have created a patch which adds soname support when making shared libraries on linux.

http://github.com/shtylman/mongo/commit/b024e7a38d0ecf38368dca177b5cf92afde61dce



 Comments   
Comment by Andrew Morrow (Inactive) [ 08/Jan/15 ]

Hi Tim -

In general, we are of course in favor of appropriate use of SONAME. However, the only thing worse than not having a SONAME is having one and getting it wrong. As you note, the legacy driver (both in its in-tree and now out of tree incarnations) does not have a particularly coherent design. Given the design deficiencies, the developers are unsure that we would be able to both be responsive to the inevitable bugs and minor feature requests, and honor any stated ABI without needing to bump the SONAME on every release, effectively rendering it useless. So for now we are only planning to offer source level compatibility between point releases for the legacy driver. If there is sufficient push back, we may reconsider, but for now we are not planning to invest time in establishing a SONAME for the legacy driver.

Please note that we will definitely not be re-using the library name (or symbol names) for the C++11 driver, so there is no risk of confusion there.

I do appreciate your taking the time to look at the proposed C++11 interfaces and I'm happy to hear that you find it promising. Your point about enterprise distributions is true (though, do take note of the RHEL C++11 toolchain). Our hope is that the majority of new systems development can migrate to the C++11 driver, away from the legacy driver. For developers who are not able to take advantage of C++11, we also offer an ABI stable C driver. Our expectation is that between these three options (source level C++03 driver, ABI C driver, ABI C++11 driver) one will be appropriate for most needs.

Thanks,
Andrew

Comment by Tim Niemueller [ 08/Jan/15 ]

Hi Andrew.

Thanks for the clarification. Even though you intend to deprecate the existing driver in favor of a new one, it should be clear that many projects will (at least for some time) continue to use the existing driver. Additionally, current enterprise Linux distributions will stick to that very version for the version life cycle (they promise a stable base system) and maybe only additionally provide the new driver. This is especially so since they come with older compilers with incomplete C++11 support (which they are definitely not going to update). Therefore, I would suggest to also add an SONAME to the legacy driver, as it will stick around for some time to come. Especially if the new driver were to use the same library names etc., then the SONAME might be the only thing to clearly state the proper dependencies for compiled code. Otherwise it can be helpful e.g. when later adding security-related patch or similar.

I do appreciate for a new and cleaned up/simplified C++ driver. Just from my experience with the in-tree C++ driver (and not yet so much with mongo-cxx-driver) it is clear that it is not super coherent and the code could use better structuring. The commit you send already looks promising. So I'm looking forward to it!

Regards,
Tim

Comment by Andrew Morrow (Inactive) [ 07/Jan/15 ]

Hi Tim -

The driver is called "legacy" because we are planning to supplant it with a new, modern, C++11 driver, and because the legacy driver will not be brought into conformance with future drivers specifications. The new driver will be aligned with the terminology and structure of other MongoDB drivers, and will most likely be implemented as a lightweight wrapper around the C driver. We anticipate that the design of the new driver will allow us to provide a stable ABI, at which point a SONAME would become possible.

If you are interested in getting a preview of what the C++11 driver might look like, have a look at this commit: https://github.com/mongodb/mongo-cxx-driver/commit/c36a4043f3d766deed50c1cc39261505293711ec

We are still doing internal review and the API is likely to evolve. Once we have finished our internal review we intend to solicit public comment on the proposed driver API.

Please let me know if you have any questions or comments.

Thanks,
Andrew

Comment by Tim Niemueller [ 07/Jan/15 ]

Ok, that makes me wonder. Why is the driver called "legacy"? Is there no official support for C++ anymore?

Then, you provide an ABI whether you keep it stable or not. It would, however, make it much simpler if you did provide an soname as it will make dependency tracking much easier. Please think about your users here – most of us will track package updates on the distro level and it would be much easier if we could at least quickly see if something breaks due to a new library version indicated by an soname mismatch.

Comment by Adam Midvidy [ 07/Jan/15 ]

we are not offering an ABI for the legacy driver, therefore we will not offer a soname.

Comment by Ian Whalen (Inactive) [ 22/May/12 ]

@roman, JIRA is set up to send all updates to the reporter so I'm pulling you off as reporter and swapping myself in.

Comment by Roman Shtylman [ 22/May/12 ]

Can I please be unsubscribed from this issue? Or the issue closed? if it hasn't been done in the two years it has been open it isn't going to be done. I don't care about this anymore.

Comment by Roman Shtylman [ 29/Aug/11 ]

How can I unsubscribe from this issue?

Comment by Eliot Horowitz (Inactive) [ 09/Mar/11 ]

Nothing in particular holding this up, just hasn't made it to the top yet.
Given the patch, will move to 1.9

Comment by Roman Shtylman [ 08/Mar/11 ]

Opened the following pull request which rebases the patch on top of the latest 1.8 branch

https://github.com/mongodb/mongo/pull/27

Is there something holding this up or general opposition to this idea?

Comment by Eliot Horowitz (Inactive) [ 17/Dec/10 ]

Its triggered from the same buildbot, but just built from a separate directory.

Comment by Roman Shtylman [ 17/Dec/10 ]

Will the client code still live in the main repo? How will a client build be triggered? Or will it still be a part of the default build just in a separate scons file?

Comment by Eliot Horowitz (Inactive) [ 17/Dec/10 ]

It should really be off this:
https://github.com/mongodb/mongo/blob/master/distsrc/client/SConstruct

We're slowly deprecating building the client from the main scons file

Comment by Roman Shtylman [ 17/Dec/10 ]

Is there a reason the patch wasn't accepted? Should I rebase it off the latest master again? The longer a soname release is delayed the more problems users of a c++ library will have in future upgrades.

Generated at Wed Feb 07 21:58:25 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.