[CXX-923] Shared library is missing SONAME Created: 07/Jun/16  Updated: 08/Jun/16  Resolved: 07/Jun/16

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

Type: Bug Priority: Major - P3
Reporter: Giulio Paci Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File 1001_fix_several_issues.patch    

 Description   

When building shared library, SONAME is not set.
SONAME is useful to track ABI compatibility changes, so that programs can pick up the correct version of a library. The SONAME should be updated every time that a library changes its ABI (e.g., symbol deletion, behavior change, ...), so that it is possible to determine if a program should be recompiled when a library is updated.

Attached you can find a patch that adds SONAME. You should update the SONAME every time you release a version of the library that is not backward compatible at the ABI level. SONAME is completely unrelated to release version and mostly unrelated to API changes.



 Comments   
Comment by Giulio Paci [ 08/Jun/16 ]

For SONAME support, please have a look at the attached patch: this should be enough to properly set the SONAME and create appropriate symlinks in the build directory.

I agree that I will have to relink my applications, at every release, but:
1) I will be able to have multiple version of the library installed at the same time, so that I will not be forced to relink all of the applications at the same time and I will not be forced to update all of them at the same time;
2) I will be able to better track linking issues;

If you update the SONAME version anybody will benefit from this and, given that people are using a released version, there will also be synchronization among SONAMEs of compiled libraries that people may have in their systems (and required version of the library for the applications that they may have in their systems).

Thank you for the additional information about the new C++11 driver.

Comment by Andrew Morrow (Inactive) [ 08/Jun/16 ]

giuliopaci - I don't want to sound unsympathetic here, because I really do appreciate what you are hoping to do, but we spent two years writing a new driver exactly so that we could, finally, have a path to setting a SONAME and managing it correctly. If I have to bump the SONAME on every release of the legacy driver, what good does that do you? You would still need to re-link your application each time to pick up the new SONAME. Not to mention that the legacy driver build system currently has no mechanism to set or manage a SONAME or the versioned install symlinks. All of that infrastructure would need to be developed.

As far as the new C++11 driver, we actually have another blog post coming soon describing it in more detail. But, until that launches, here is the plan:

  • The 3.0.x release series, available now via tags on the master branch of the mongo-cxx-driver repo, is a stable driver. We are explicitly not declaring API or ABI stability in the 3.0.x release series as we felt we needed real customer usage so that API flaws could be identified and fixed. The 3.0.x driver is production quality, however you may need to recompile and re-link your application on each upgrade. This is essentially the same story as the legacy driver.
  • The 3.1.x release series, anticipated around the end of the summer, will declare API stability.
  • The 3.2.0 release, anticipated in the fall, will add support for the upcoming MongoDB 3.4 release, at which point we will set the ABI for the new driver.
Comment by Giulio Paci [ 07/Jun/16 ]

Thank you for the blog posts. I packaged the legacy driver as I am using a third-party application using it in production. This is also why I would like to have a SONAME set: to ensure production quality and smooth upgrades.

In https://www.mongodb.com/blog/post/introducing-new-c-driver you suggest to use the legacy package for production. Is this recommendation still valid? If yes, I still do not see why you are not setting the SONAME.

Basically I have to say I do not see any disadvantage in setting SONAME (and you did not mention any yet), even if you are going to EOL the legacy driver tomorrow, while I see plenty of disadvantages, especially since you recommended it for production. So please, add the SONAME. The effort will be minimal on your side (just increase the major number with every release, that, given what you are saying, are going to be a lot) and the management of current software will be much easier and safer.

On the other hand I am happy to see that the new driver is approaching and that you are going to wrap the C library, instead of maintaining a completely separated version. When do you think it will be possible to recommend the use of the new driver instead of the legacy one? When is its first proper release scheduled?

Comment by Andrew Morrow (Inactive) [ 07/Jun/16 ]

Because this is the legacy driver. It was never properly designed as a user facing library, and in particular was never designed to be packaged. I recommend reading these blog posts for more background:

We more or less aren't investing time in improving the legacy driver further outside of critical bug fixes, and we hope to start the EOL process for the legacy driver later this year.

Comment by Giulio Paci [ 07/Jun/16 ]

I agree that it is possible, but it makes it very difficult to track compatibility issues and to perform safe upgrades of compiled software: if you have multiple programs compiled against the same shared library and then want to upgrade the library, it is going to be very problematic, especially as I understand, you are not going to set a SONAME and, at the same time, you are not going to maintain ABI compatibility.

If I understood correctly and you do not want to maintain ABI compatibility, why not make it explicit in the SONAME, increasing its version at every release?

Comment by Andrew Morrow (Inactive) [ 07/Jun/16 ]

We are setting an ABI for the C++11 driver - which is a totally different project than the legacy driver. The legacy driver will never have an ABI declared. We provide a --sharedclient option so people can build it as a shared library. It is totally possible to build and use shared libraries that don't offer a SONAME.

Comment by Giulio Paci [ 07/Jun/16 ]

Good to know that you are setting an ABI in the near future.

Can you explain why you intentionally did not set a SONAME, but, at the same time, provided a --sharedclient option? It does not make much sense to me.

Am I missing something?

Comment by Andrew Morrow (Inactive) [ 07/Jun/16 ]

The legacy C++ driver will never have an ABI, and it is intentional that we do not set a SONAME. We plan to set an ABI on the new C++11 driver in the near future.

Generated at Wed Feb 07 22:00:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.