[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:
Depends

 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: MONGOCRYPT-217 hide and version libbson symbols

  • on macOS hide libbson symbols with -unexported_symbols_list
  • on Linux, hide and version libbson symbols with --version-script

Hiding the libbson symbols prevents external libraries from using them.
Versioning the libbson symbols prevents (on Linux) libmongocrypt from
finding matching libbson symbols exposed from external libraries. On
macOS, versioning does not appear necessary as libmongocrypt always
appears to use the statically linked libbson symbols.
Branch: master
https://github.com/mongodb/libmongocrypt/commit/217072a3f089820e9690ff03d3394c42d1d4cd20

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 ]

Additionally, the libbson to which libmongocrypt links will need to be added to the libmongocrypt package which is provided via the PPA.

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)?

Generated at Thu Feb 08 09:08:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.