[MONGOCRYPT-217] Hide libbson symbols in libmongocrypt Created: 10/Dec/19 Updated: 28/Oct/23 Resolved: 08/Jan/20 |
|
| Status: | Closed |
| Project: | Libmongocrypt |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 1.0.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Roberto Sanchez | Assignee: | Kevin Albertson |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Description |
|
The current approach to building libmongocrypt statically links it to libbson. However, this creates problems for users who link their applications to both libmongocrypt and also directly to libbson. The problems result from potential symbol collisions between the libbson symbols which are in libmongocrypt via the static linking and the libbson symbols from the attempt to link directly to libbson. The solution is to switch libmongocrypt to dynamically link to libbson. However, to prevent collisions with files which might be installed by the libbson package included in various distribution repositories, the libbson used by libmongocrypt must be located in a private subdirectory (e.g., /usr/lib/mongocrypt) and linkage from libmongocrypt to that particular libbson will need to be managed with rpath. Additionally, the libbson to which libmongocrypt links will need to be added to the libmongocrypt package which is provided via the PPA. divjot.arora, could you take a look at what is proposed here and let me know if you think it might negatively affect the Go driver? CC: kevin.albertson |
| Comments |
| Comment by Githook User [ 02/Jan/20 ] |
|
Author: {'name': 'Kevin Albertson', 'email': 'kevin.albertson@mongodb.com', 'username': 'kevinAlbs'}Message:
Hiding the libbson symbols prevents external libraries from using them. |
| Comment by Kevin Albertson [ 12/Dec/19 ] |
|
Per discussion, let's flesh out the options in WRITING-4771 so we're all in agreement. |
| Comment by Roberto Sanchez [ 12/Dec/19 ] |
|
jmikola, we could, but it would introduce the potential for future complications. All we really want is a dynamically linked private libbson for use by libmongocrypt. kevin.albertson and I discussed this and if we provide a libbson package then we have consider alternate naming, conflicts with distro-provided libbson packages, etc. We can avoid that by just shipping the libbson artifact in a subdirectory of /usr/lib (which is the convention for private libraries) and achieve our objective without the complications. |
| Comment by Jeremy Mikola [ 12/Dec/19 ] |
Can we consider making a separate libbson package and declaring the dependency in the libmongocrypt package? As far as PPAs are concerned, I don't see why this would conflict. Using Ubuntu PHP packages as example, there are PPAs that provide newer builds of PHP binaries with newer version numbers than the equivalently named packages in the main Ubuntu repos – and I don't believe there's any issue with these co-existing. |
| Comment by Kevin Albertson [ 11/Dec/19 ] |
|
Right, this should not make any change to the output of pkg-config. Internally libmongocrypt will no longer contain libbson symbols, but rather have a link to a shared libbson library that it would not expose directly. Off-hand I don't foresee any issues. I don't think users will need to recompile their applications if they've upgraded libmongocrypt. But we should certainly dry-run this, and for libmongoc too. We can do an rc release (or manually upload packages) to a different location and test them before we overwrite the production packages in a real release. |
| Comment by Divjot Arora (Inactive) [ 11/Dec/19 ] |
|
roberto.sanchez I don't think this should cause any issues for Go. From what you're saying, it sounds like the new linking process is more complex than the current one, but it will all be managed by the PPA, correct? However, I'm not at all certain about this and the Go driver is currently building from source on Ubuntu machines in Evergreen because we were seeing transient apt issues, so we wouldn't know if this actually works. Is it possible to "dry-run" this (e.g. test with the Go driver before releasing)? |