[SERVER-2180] Make tools use shared library Created: 06/Dec/10  Updated: 23/Jun/15  Resolved: 23/Jun/15

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Tim Niemueller Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux x86_64


Issue Links:
Related
is related to CXX-42 Create a C++ driver redistributable p... Closed
Participants:

 Description   

Currently tools like mongodump link all required objects into the binary. The commonFiles variable in SConstruct demonstrates this.

It would be much more efficient if the tools would link against the shared mongoclient library (which also includes commonFiles). Especially on a loaded system where many of those tools (and other client applications) run at the same time this can considerably lower the memory footprint and improve cache performance. It would also improve MongoDB's conformance with packaging guidelines like the one of Fedora.



 Comments   
Comment by Ian Whalen (Inactive) [ 23/Jun/15 ]

As of the 3.0.0 release all of the mongo* tools have been rewritten in Go, and the new code can be found at https://github.com/mongodb/mongo-tools.

Any future improvements or feature requests related to the rewritten tools can be filed here: https://jira.mongodb.org/browse/TOOLS.

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

using a static library will make binaries larger on some platforms, so i'd rather not do that by default.

Comment by Tim Niemueller [ 07/Dec/10 ]

Why make it a separate ticket?

So after further thinking about it I think the best solution is to use the library when linking the tools, no matter if it is the shared or the static library. If the shared library is used it improves things, if the static one is used it stays the same.

Would that be a suitable change?

The change is then in changing the link and target file options of the tools, rather than forcing a shared library on them. If you agree I'll fork and implement this.

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

An option might be ok.
Want to make a different ticket?

Comment by Tim Niemueller [ 06/Dec/10 ]

Why not make it an option in the build system? Most of the users will enjoy packages that come with the Linux system of their choice and it'll be great if MongoDB would better blend in, and support more efficient memory usage.

At the same time you can keep the shared library optional as now. If it is not built, you simply link the programs against the static library, essentially resulting in similar binaries to the ones now.

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

There are 2 types of packages, official .tar.gz packages and distribution packages (rpm, etc)

for .tar.gz the binaries are not put in a pre-determined place, so you can't use a .so

Comment by Tim Niemueller [ 06/Dec/10 ]

Can you give a little detail what you mean by that? I mean virtually everything is used from shared libraries these days, certainly on Linux systems. I wouldn't mind making it this way on Linux only and keep it the way it is for other systems. Maybe if you give some info we could figure out a solution which is beneficial for everybody.

Issues #CDRIVER-24 and #SERVER-1949 are somewhat related in that they request a better integration into a Linux system.

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

For some packages this might be an option, but for most systems its not feasible since shard library loading is path dependant.

Generated at Thu Feb 08 02:59:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.