[SERVER-6514] scons --sharedclient mongoclient builds libmongoclient.a, no shared library build. Created: 19/Jul/12  Updated: 05/Nov/15  Resolved: 18/Jun/13

Status: Closed
Project: Core Server
Component/s: Internal Client
Affects Version/s: 2.1.2
Fix Version/s: 2.4.5, 2.5.1

Type: Bug Priority: Major - P3
Reporter: Alex Syrnikov Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux x64 glibc 2.16


Attachments: File config.log     File conftest_3_bis.cpp     File ld-open-boost_system-lucid.list     File mongodb-2.2-fix-sharedclient.patch    
Issue Links:
Depends
depends on SERVER-9890 Solaris/SmartOS client program "authT... Closed
depends on SERVER-9941 sharedclient tests failing to find li... Closed
depends on SERVER-9942 smokeClient re-runs some tests with t... Closed
is depended on by CXX-172 on linux systems it is customary to u... Closed
Duplicate
is duplicated by SERVER-9221 C++ driver's shared library build is ... Closed
is duplicated by SERVER-6941 Enable shared client library build Closed
is duplicated by SERVER-6920 how can i compile the mongo driver C+... Closed
Related
related to SERVER-9771 Enable support for building the C++ d... Closed
is related to CXX-42 Create a C++ driver redistributable p... Closed
is related to SERVER-13722 Allow scons to pick up paths for shar... Closed
Operating System: ALL
Participants:

 Description   

scons --sharedclient mongoclient
builds nonshared library libmongoclient.a but no shared library build.
I have used some 2.1.3-pre- version from github.



 Comments   
Comment by Ultrabug [ 28/Jun/13 ]

Thx a bunch Johan & Andrew.

Comment by Johan Hedin [ 27/Jun/13 ]

acm, Ultrabug here you go: SERVER-10049

Comment by Johan Hedin [ 27/Jun/13 ]

Sorry, spent all my time building stuff around mongodb than building mongodb itself...

I will post a note here to let you know when I have filed the ticket. Thanks for the reminder though!

Comment by Andrew Morrow (Inactive) [ 27/Jun/13 ]

jhn ultrabug Johan/Ultrabug, did either of you file a ticket for the lib64 issue? I want to ensure that it gets tracked.

Thanks,
Andrew

Comment by Ultrabug [ 25/Jun/13 ]

Thx Johan Hedin, please link here the issue you'll open, I'll do my best to follow it up and help if I can.

Comment by Johan Hedin [ 24/Jun/13 ]

Hi Andrew

You are right about the use of ${LIBPREFIX}, I was just blinded by all the code so I mistook it for something else

The patch I'm running on 2.4.3 and 2.4.4 so far is parts from this pull request: https://github.com/mongodb/mongo/pull/406 (mentioned above in this ticket). I just took as much as required for the library to build and when I got so far I stopped. Might be as you say that the line on https://github.com/mongodb/mongo/blob/r2.4.4/src/SConscript.client#L140? didn't do anything. But anyhow, this small patch on 2.4.3 build libmongoclient.so and installed it in /usr/lib64:

--- mongodb-src-r2.4.3.orig/src/SConscript.client       2013-04-11 15:14:52.000000000 +0200
+++ mongodb-src-r2.4.3/src/SConscript.client    2013-04-13 22:08:42.316893259 +0200
@@ -49,6 +49,9 @@
     'mongo/db/dbmessage.cpp',
     'mongo/pch.cpp',
     'mongo/platform/random.cpp',
+    'mongo/s/field_parser.cpp',
+    'mongo/s/type_lockpings.cpp',
+    'mongo/s/type_locks.cpp',
     'mongo/util/assert_util.cpp',
     'mongo/util/background.cpp',
     'mongo/util/base64.cpp',
@@ -59,8 +62,11 @@
     'mongo/util/concurrency/thread_pool.cpp',
     'mongo/util/concurrency/mutexdebugger.cpp',
     'mongo/util/debug_util.cpp',
+    'mongo/util/processinfo_linux2.cpp',
+    'mongo/util/processinfo.cpp',
     'mongo/util/stacktrace.cpp',
     'mongo/util/file_allocator.cpp',
+    'mongo/util/file.cpp',
     'mongo/util/fail_point.cpp',
     'mongo/util/fail_point_registry.cpp',
     'mongo/util/fail_point_service.cpp',
@@ -137,7 +143,7 @@
 mongoclient_lib = env.Library('mongoclient', clientSource),
 mongoclient_install = env.Install('#/', [
         mongoclient_lib,
-        #env.SharedLibrary('mongoclient', clientSource),
+        env.SharedLibrary('mongoclient', clientSource),
         ])
 env.Alias('mongoclient', mongoclient_install)
 

I can't explain why though

I build mongodb 2.4.3 and 2.4.4 inside a RPM with the following arguments:

scons install \
        -j5 \
        --sharedclient \
        --use-system-all \
        --prefix=<path_to_temp_buildroot>/usr \
        --extrapath=/usr \
        --usev8 \
        --nostrip \
        --ssl \
        --full

And libmongclient.so end up in <path_to_temp_buildroot>/usr/lib64.

I don't know how scons usually handles the issue with libraries in different places on different distributions and I agree fully with you that it is bad to code in distribution specific paths in the build system.

I guess that the proper way to do it is as in automake/autoconf and friends where you have a hard coded standard path with the possibility to override it at build time so that you easily can place the files where the belong in your distribution of choice (with --libdir --includedir --bindir etc.)

Thanks for the comments anyway. I'm going to creating a new ticket to track this new issue.

Comment by Andrew Morrow (Inactive) [ 24/Jun/13 ]

Hi Johan -

I agree that we should not be installing the 64-bit library to /usr/lib if /usr/lib64 is the proper target for 64-bit libraries. I'm a bit puzzled about your comment about "the line that is commented out"? Are you referring to this line in 2.4.4: https://github.com/mongodb/mongo/blob/r2.4.4/src/SConscript.client#L140? If so, I think all that line would do is install libmongoclient.so to the root of the mongodb source tree at build time, not to the 'prefix' library directory.

As far as LIBPREFIX, I believe that this is just the 'lib' part of 'libfoo.a', and the analogue for shared libraries is SHLIBPREFIX, also typically 'lib'. I'd be surprised if this had any variation associated with the target architecture. But it should be easy enough to check. Can you, on your fedora machine, print out what LIBPREFIX is set to? You should just be able to say:

print(env['LIBPREFIX'])
print(env['SHLIBPREFIX'])

or something similar.

So I'm not entirely sure how things would have worked before to install it to /usr/lib64 in 2.4.4: I don't see anything that would actually make that happen, but perhaps I'm overlooking it. If you do know where that happens, please let me know.

I suspect though that what needs to happen here is somewhat more sophisticated than just detecting redhat or Gentoo and jamming a '64' on there. Ideally this should work across many different bi- and multi-arch mechanisms. Also consider that a perfectly valid way to build and install mongodb is to set a prefix that is "isolated" and not a standard system prefix, e.g. --prefix=/my/custom/build, in which case it is probably wrong to adopt multiarch or FHS style library directory naming conventions. Or maybe it is fine to do so, or should be a user choice. But presumably we need to ask the local operating system what the proper adornment for the library directory is for a particular target architecture.

Overall I think there is a fair amount of work that needs to be done here that is independent of the original purpose of this ticket, which was to get the shared library building at all. But I agree that this is something that should work correctly out of the box.

Given all of that, I'd suggest that you open a new server ticket so we can track progress there.

Comment by Johan Hedin [ 24/Jun/13 ]

I'm seeing the same issue regarding lib vs lib64 as Ultrabug.

When building the current 2.4 branch from git on a x86_64 Fedora machine, libmongoclient.so gets installed in /usr/lib instead of /usr/lib64 which is the normal place on 64-bit RedHat based distributions.

For 2.4.4 the install phase for the .so file was commented out, but if you brought that line back, the .so file was actually installed in /usr/lib64 on 64-bit machines.

I see that src/SConscipt.cilent for 2.4.4 contain this line:

env.Install(prefix + "/lib", '${LIBPREFIX}mongoclient${LIBSUFFIX}')

so I'm guessing that ${LIBPREFIX} is what makes this work on 2.4.4 but not on 2.4-latest.

libmongoclient.a has always been installed in /usr/lib for both 32 and 64-bit.

Do you think it would be possible to get proper /usr/lib64 handling? Perhaps with some way of passing the desired lib-path into scons like in 2.4.4?

Comment by auto [ 07/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Don't attempt to test shared library clients for out of tree builds
(cherry picked from commit 8e424563048f15a8a7f2fe6de1ad40131a75580b)
Branch: v2.4
https://github.com/mongodb/mongo/commit/9c4382ecb90f1044e3ba0e38991cf5c45281b7ea

Comment by auto [ 07/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Only apply -zdefs and --as-needed to shared client library
(cherry picked from commit ce97dc76c6a3f399f2f67613a55a7c238384ede9)
Branch: v2.4
https://github.com/mongodb/mongo/commit/288d347dbfcd99f49f75b8d2313aa49429b9119c

Comment by auto [ 07/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Only run global initializers from httpClientTest for in-tree SSL builds
(cherry picked from commit 3ba5acdb56f4268f56debd18db0fd6cf962572b4)
Branch: v2.4
https://github.com/mongodb/mongo/commit/6975c883e8c431985037ded4a6d78c92f0a7c802

Comment by auto [ 07/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Ensure libmongclient precedes other libraries
(cherry picked from commit 8752f3576634716b3ff81b8d0d99b5b6abc61165)
Branch: v2.4
https://github.com/mongodb/mongo/commit/bc08f8a73aeedb1511c699290029e22e9bad1324

Comment by auto [ 07/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Don't override CheckLib solution when using system boost
(cherry picked from commit cfc88a35ce57ef8552233cc10a74af0e59f29200)
Branch: v2.4
https://github.com/mongodb/mongo/commit/01fa5e94422bdd29810e1aa5e5db54b6ce68fc24

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

trsystran If you are installing boost to a location not on the default search path, you should use the dll-path argument to b2 to configure an RPATH to the install location to be encoded in each .so so that the installation library directory is searched for dependencies at link time.

I've verified this by:

  • Building boost 1.53 in a lucid chroot without dll-path
  • Compiling mongo master with --use-system-boost --sharedclient --extrapathdyn=<path-to-boost-install>
  • Verifying that the configure step fails as you observe in the configure step
  • Re-building boost 1.53 with dll-path pointing to the install path lib directory
  • Verifying that mongo's configure step now passes
Comment by Thomas Riccardi [ 07/Jun/13 ]

acm none of the boost*.so I used here have RPATH: my own build, and the ones from ubuntu.

I confirm your experiment with RPATH: if RPATH is set, then at link time those path will be searched, and -L path wont. I didn't know that (and I still don't understand why -L is not searched...).

However it does not solve our issue, unless you are OK with the fact that the conf_test3 tests boost_thread's own dependences only with lucid, and not with raring. In other words: you impose RPATH for lucid users.

Also, you impose RPATH to all users if boost has a new internal dependency not listed in boostLibs.

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

trsystran What is the RPATH set in /home/vagrant/boost-1.53.0/lib/libboost_thread.so? I've tested with a little toy program in a Lucid chroot and verified that the lucid linker does in fact find indirect dependencies at link time via RPATH. I've put the experiment up on github so you can try it yourself: https://github.com/acmorrow/solib-rpath-test. I've tested this on Lucid, Precise, and Raring, using both binutils.bfd and binutils.gold. In all cases, the build of the client against libraries built with --use-rpath-in-libs passes.

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

ultrabug Thanks for the info on the gentoo patches.

I don't really understand the first patch you linked. From what I can see, this only affects whether the boost version flags affect the variant directory. I don't see how doing that would help anything at all.

For the second patch, it is hard to evaluate in the context of the changes we are making since so much of the SConscript.client has changed. I think we have taken care of many of the issues your patch is addressing though. RE '/lib': Is the issue that for 64 bit builds you are building with a prefix of '/usr', but expect the target directory for 64 bit libraries to be /lib64 rather than /lib?

Comment by Thomas Riccardi [ 07/Jun/13 ]

Andrew,

I straced the g++ command on both lucid and raring:

g++ -o .scons/Linux/nohost/sconf_temp/conftest_3 -fPIC -pthread -rdynamic .scons/Linux/nohost/sconf_temp/conftest_3.o -L/home/vagrant/boost-1.53.0/lib -L/home/vagrant/boost-1.53.0/lib64 -L/usr/lib64 -L/lib64 -Wl,--start-group -Wl,--end-group -lm -lpthread -lboost_thread

On lucid it searches libboost_system.so.1.53.0 in many directories, but none specified via -L, then it prints the error (see ld-open-boost_system-lucid.list).

On raring, there is no mention to boost_system at all, and it works. (I also tested on precise, it's the same as on raring).

With --as-needed lucid behaves like raring, and with --no-as-needed raring behaves like lucid.
So the default behaviour has changed between lucid and raring, and for my lucid build I will need the --as-needed flag.

I did one more test to check your assumptions of your last comment: I patched conftest_3.cpp to actually use a symbol in boost_thread that depends on a symbol in boost_system: boost::thread_exception inherits from boost::system::system_error.
The build of conftest_3_bis.o works, but the link fails, both on lucid and raring:

g++ -o .scons/Linux/nohost/sconf_temp/conftest_3_bis.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -pipe -fno-builtin-memcmp -O3 -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -D_FILE_OFFSET_BITS=64 -Ibuild/linux2/extrapathdyn__home_vagrant_boost-1.53.0_/use-system-boost/third_party/libstemmer_c/include -Ibuild/linux2/extrapathdyn__home_vagrant_boost-1.53.0_/use-system-boost/third_party/s2 -Ibuild/linux2/extrapathdyn__home_vagrant_boost-1.53.0_/use-system-boost/third_party/pcre-8.30 -Ibuild/linux2/extrapathdyn__home_vagrant_boost-1.53.0_/use-system-boost -Ibuild/linux2/extrapathdyn__home_vagrant_boost-1.53.0_/use-system-boost/mongo -I/home/vagrant/boost-1.53.0/include .scons/Linux/nohost/sconf_temp/conftest_3_bis.cpp
 
g++ -o .scons/Linux/nohost/sconf_temp/conftest_3_bis -fPIC -pthread -rdynamic .scons/Linux/nohost/sconf_temp/conftest_3_bis.o -L/home/vagrant/boost-1.53.0/lib -L/home/vagrant/boost-1.53.0/lib64 -L/usr/lib64 -L/lib64 -Wl,--start-group -Wl,--end-group -lm -lpthread -lboost_thread 
 
/usr/bin/ld: warning: libboost_system.so.1.53.0, needed by /home/vagrant/boost-1.53.0/lib/libboost_thread.so, not found (try using -rpath or -rpath-link)
.scons/Linux/nohost/sconf_temp/conftest_3_bis.o: In function `__static_initialization_and_destruction_0':
/home/vagrant/boost-1.53.0/include/boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()'
/home/vagrant/boost-1.53.0/include/boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()'
/home/vagrant/boost-1.53.0/include/boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()'

If I add -lboost_system, then it works everywhere.

So, the conftest_3 does not fully check if boost_thread is usable because of the previous --as-needed on lucid, and because of a different behaviour (an optimization?) on precise & raring. This only works because boost_system is also tested this way later on. This however requires to store in the mongodb build system the (flattened) dependency graph, which you said would not be great. Luckily you explicitly use all the dependencies already.

Comment by Ultrabug [ 07/Jun/13 ]

Just FYI in case it's related or can contribute to your issue, we Gentoo folks have to apply this patch to get mongodb compile with possible multiple versions of boost

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/mongodb/files/mongodb-2.2-r1-fix-boost.patch?revision=1.1&view=markup

As for the --sharedclient issue, we also have to patch this way (also for new SASL2 support)

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-db/mongodb/files/mongodb-2.4.4-fix-sharedclient.patch?revision=1.1&view=markup

Please note that we also have to do some magic because of the harcoding of '/lib' in the src/SConscript.client file which is not respecting /usr/lib64 users.

Regards

Comment by Andrew Morrow (Inactive) [ 06/Jun/13 ]

I am fairly sure that if you have 'liba.so', which depends on 'libb.so', and you have 'program' which links only against 'liba.so' by saying '-la', then you should not need to recursively list the dependencies of 'liba.so' if 'libb.so' can be found according to 'liba.so's search path (RPATH). Also keep in mind that certain directories are searched by default (like /usr/lib) for dependencies, so if the libraries are installed to /usr/lib, they do not need a search path set to find indirect dependencies according to this algorithm.

This at least has been my experience on modern linux systems. Darwin and Windows of course work differently.

Comment by Thomas Riccardi [ 06/Jun/13 ]

More test:
I installed a raring VM, mongodb 2.4.4 sources, the first 2 commits cherrypicked, installed ubuntu boost_thread and boost_system and -dev.
... and it works.
I don't understand why.

I then copied the libs & includes in a ~/boost-1.53.0 directory, and removed the ubuntu packages, it still works.

I then tested with lib & include from my own boost build, and it still works too...

So now the only differences are on the compilation tool side...

Comment by Thomas Riccardi [ 06/Jun/13 ]

My original setup is a manual rebuild of the entire boost on lucid.

I tested with Raring boost .debs to check if they contained RPATH, as you explained it could be needed. This was just to test the linker behaviour, I know it would not work anyway since libstdc++ is not the same in raring and lucid.
I unpacked them to /home/riccardi/boost-1.53.0/lib to replace my own .so.
And it didn't work.

Ayway, unless I'm wrong, the link step requires all dependences recursively with -l. So the check for boost_thread done by scons is missing -lboost_system.
I don't see how it can work without.
Setting a RPATH or putting the libs in /usr/lib won't affect the link step (as all relevant paths are already given by -L), but will be only used at runtime.

Comment by auto [ 06/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Don't attempt to test shared library clients for out of tree builds
Branch: master
https://github.com/mongodb/mongo/commit/8e424563048f15a8a7f2fe6de1ad40131a75580b

Comment by auto [ 06/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Only apply -zdefs and --as-needed to shared client library
Branch: master
https://github.com/mongodb/mongo/commit/ce97dc76c6a3f399f2f67613a55a7c238384ede9

Comment by Andrew Morrow (Inactive) [ 06/Jun/13 ]

Thomas -

OK, lets focus on your boost setup then. From what I've read above, you have taken the Raring boost .deb's, and unpacked them on a Lucid machine? Did you unpack them to /usr/lib? From earlier, it looked as if you had the boost libraries in /home/riccardi/boost-1.53.0? It is quite unlikely that the Raring boost .deb's will work correctly on Lucid. If you need a newer boost, you will need to build from source on Lucid.

I'm still working on an answer to some of your RPATH questions.

Comment by Thomas Riccardi [ 06/Jun/13 ]

Indeed, "--as-needed" hid the fact that boost linking was not correctly done when checking for boost_thread validity.

But since boost_system is checked after that, it's not that much wrong as it won't accept an invalid config after all.

Comment by Andrew Morrow (Inactive) [ 06/Jun/13 ]

Hi Thomas -

I'll keep looking into why this doesn't work for you, but do you agree that the change to LINKFLAGS/SHLINKFLAGS is not the root cause? My interpretation of what we have found so far is that removing it just exposed a latent problem of some sort rather than directly causing the problem.

Andrew

Comment by Thomas Riccardi [ 06/Jun/13 ]

objdump -p libboost_thread.so | grep NEEDED

This returns among other things libboost_system.so.1.53.0. But this lib is in the same lib/ directory as libboost_thread.so.

1) I confirm that without --sharedclient mongod target also fails to find boost. But I don't need to build anything else than the C++ client driver.

With 2.0 I used the tarball with "scons install", and with 2.2 I used the same scons options as now: "--use-system-boost --extrapathdyn=... --sharedclient mongoclient" and it worked (modulo patches to support newer boost, but the work is done in 2.4 now).

2) I don't use RPATH in my build system: correct -l, -L on link and LD_LIBRARY_PATH at runtime work great. Until now with mongodb.

I tested with boost_thread & boost_system 1.53.0 from ubuntu raring, they don't have any RPATH or RUNPATH, and the issue is the same. (I'm on ubuntu lucid, boost 1.40 is too old, so I extracted the .so from the raring .deb, and put them in my lib/ to test.)

I don't see how it could work if no -lboost_system is set. RPATH or /usr/lib will help at runtime, but not at linktime, will they?

Comment by Andrew Morrow (Inactive) [ 06/Jun/13 ]

Hi Thomas -

That is very interesting. Here is what I think is going on. Your boost_thread.so has a dependency on symbols from boost_system.so and has a DT_NEEDED entry for that library.

When we previously had -Wl,--as-needed on the LINKFLAGS it would get used to build the trivial configure executable, which does not have any real dependencies on boost_thread.so, so because of --as-needed, the linker would discard the dependency on boost_thread.

When we remove --as-needed the dependency on boost_system.so is no longer discarded, but when the linker tries to actually use found boost_thread.so, it fails because it is unable to find boost_system.so by any of its usual search mechanisms, even though the library exists.

A few follow up questions:

1) How did this build environment work before? If you weren't building with --sharedclient, we weren't passing --as-needed, but previously --sharedclient was broken, so there was no point in passing it. So I would expect that this build environment would not have been functional to just build, say, mongod either. Can you confirm that if you don't use --sharedclient that other targets fail to build in the same way?

2) Typically I would expect your libboost_thread.so in /home/riccardi/boost-1.53.0/lib to have that directory set in its DT_RPATH or DT_RUNPATH entry so that the linker knows where to look for its dependent libraries.

My suspicion is that if you built against boost libraries installed to /usr/lib that this problem would go away. Another solution would be to investigate why your boost libraries are not built with a runpath encoded. Finally, yet another possibility would be for us to CheckLib the boost libraries in reverse dependency order, since as each CheckLib completes successfully the libraries would be explicitly added to the link line and therefore they would be found via the -L search mechanism, rather than by RPATH-y mechanisms. This last solution is my least favorite however, as it requires us to encode knowledge about the boost library dependency graph into our build environment, which is a fragile solution.

Comment by Thomas Riccardi [ 06/Jun/13 ]

config.log without manual patch: boost_thread not found.

Commandline:
scons --use-system-boost --extrapathdyn=/home/riccardi/boost-1.53.0 --sharedclient mongoclient -j4

SHLINKFLAGS are not added to the compile command line, but LINKFLAGS are, and without "Wl,-as-needed" the boost .so are not found.

(config.log is a lot simpler than what I did originally to find the solution: with strace...)

Comment by Andrew Morrow (Inactive) [ 05/Jun/13 ]

Hi Thomas -

I've just pushed to master three fixup commits for this ticket. One fixes up the second of the two issues you identified, and the others fix some other minor issues we have discovered internally. I'm going to let these burn in on master and (assuming all is well there), backport them to 2.4 soon. You can probably cherry pick them to 2.4 yourself to test if you like.

Regarding your comments on LINKFLAGS/SHLINKFLAGS: I'd be very surprised if this was the cause of your problem. These flags should only be in SHLINKFLAGS, since they are only intended to alter the link flags for the shared client library. Adding them to LINKFLAGS spams the flags over all other targets in the build, changing the link line for targets like mongod when --sharedclient is enabled, which is not intended. These flags really do belong on SHLINKFLAGS, and I don't see how their removal could affect the configure time detection of boost. If you can take a closer look into why the configure tests are failing on 2.4 that would very be helpful. You should be able to find the configure log 'config.log' somewhere under your '.scons' directory, which should provide additional details. It is of course possible that there is some surprising interaction, in which case we will revert the change to SHLINKFLAGS on v2.4.

Thanks again for testing this change,
Andrew

Comment by auto [ 05/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Only run global initializers from httpClientTest for in-tree SSL builds
Branch: master
https://github.com/mongodb/mongo/commit/3ba5acdb56f4268f56debd18db0fd6cf962572b4

Comment by auto [ 05/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Ensure libmongclient precedes other libraries
Branch: master
https://github.com/mongodb/mongo/commit/8752f3576634716b3ff81b8d0d99b5b6abc61165

Comment by auto [ 05/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Don't override CheckLib solution when using system boost
Branch: master
https://github.com/mongodb/mongo/commit/cfc88a35ce57ef8552233cc10a74af0e59f29200

Comment by Andrew Morrow (Inactive) [ 05/Jun/13 ]

Thomas, can you revert your change for 1, re-run and post the relevant output from config.log?

Comment by Andrew Morrow (Inactive) [ 05/Jun/13 ]

No, lets keep the tracking issues in this ticket. Thanks for testing and reporting your findings, I will look into both. I suspect 1 is just a mistake: the SHLINKFLAGS should have been added, but LINKFLAGS should not have been removed. I would like to better understand why though it caused your boost check to miss the non -mt library.

For 2, I'm working on a fix right now. I'll post an update to this ticket when these are resolved (probably first on master, then backported).

Comment by Thomas Riccardi [ 05/Jun/13 ]

I cherrypicked https://github.com/mongodb/mongo/commit/5316bea80670d924ec2d0cc3906d026882b24951 and https://github.com/mongodb/mongo/commit/9f980baa3c9ff301695a977956b56335e6774f95 on 2.4.4, and had the following issues:

I build with "scons --use-system-boost --extrapath=/path/to/my/boost/1.53.0 --sharedclient mongoclient".

1/

scons: Reading SConscript files ...
scons version: 1.2.0.d20100117
python version: 2 6 5 'final' 0
Checking whether the C++ compiler worksyes
Checking for C++ header file boost/filesystem/operations.hpp... yes
Checking for C++ library boost_thread-mt... no
Checking for C++ library boost_thread... no

I don't have boost_thread-mt but I do have boost_thread in extrapath/lib.

I found that

-Wl,--as-needed -Wl,-zdefs

has disappeared from the compilation test command line with the two cherrypicks.
It's because of this diff in SConstruct:

@@ -709,7 +712,7 @@ if nix:
             pass
 
     if linux and has_option( "sharedclient" ):
-        env.Append( LINKFLAGS=" -Wl,--as-needed -Wl,-zdefs " )
+        env.Append( SHLINKFLAGS=" -Wl,--as-needed -Wl,-zdefs " )
 
     if linux and has_option( "gcov" ):
         env.Append( CXXFLAGS=" -fprofile-arcs -ftest-coverage " )

When reverting or keeping both lines, the test correctly finds boost_thread again.

2/ After the previous fix, .o files are built, but the final link fails:

/usr/bin/ld: cannot find -lboost_thread-mt
collect2: ld returned 1 exit status

I found the issue in this code added by 5316bea8 in src/SConscript.client:160:

if use_system_version_of_library("boost"):
    mongoClientLibs.append(['boost_thread-mt'])
else:
    mongoClientLibDeps.append(['$BUILD_DIR/third_party/shim_boost'])

Detection of -mt or non -mt is ignored and -mt is hardcoded here.

When fixing this sharedclient/libmongoclient.so is finally built.

Should I open a new bug for this?

Comment by auto [ 05/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Fix accidental backport of future use of ProcessId to 2.4 branch
Branch: v2.4
https://github.com/mongodb/mongo/commit/28c04eb6fef5652d12cfbd0dd0bfe5cb0b18e26a

Comment by Eric Milkie [ 05/Jun/13 ]

It broke the 2.4 branch (does not compile)

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Don't package bsondemo.cpp twice
Branch: master
https://github.com/mongodb/mongo/commit/9f980baa3c9ff301695a977956b56335e6774f95

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Re-add support for building the C++ driver shared library

Primarily a backport of da8c0fa929eeb03dbe3fb0533874de31da0bc8c8, with
the following SERVER-6514 fixups patches from master rolled in as well:

680f0bf57260bf020cfaeb35598861c6b89524cb
48f8431210aba4de7d108852bc1d87267237d358
Branch: v2.4
https://github.com/mongodb/mongo/commit/5316bea80670d924ec2d0cc3906d026882b24951

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Re-add support for building the C++ driver shared library

Primarily a backport of da8c0fa929eeb03dbe3fb0533874de31da0bc8c8, with
the following SERVER-6514 fixups patches from master rolled in as well:

680f0bf57260bf020cfaeb35598861c6b89524cb
48f8431210aba4de7d108852bc1d87267237d358
Branch: v2.4
https://github.com/mongodb/mongo/commit/5316bea80670d924ec2d0cc3906d026882b24951

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Don't depend on InstallVersionedLibrary; only in SCons 2.3.0+
Branch: master
https://github.com/mongodb/mongo/commit/48f8431210aba4de7d108852bc1d87267237d358

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Fix build of bsondemo on Windows by using the correct header
Branch: master
https://github.com/mongodb/mongo/commit/0a8bf519fd6c3e50718f2b27fdd9e006cabee221

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Fix client build on solaris by cloning the none processinfo
Branch: master
https://github.com/mongodb/mongo/commit/680f0bf57260bf020cfaeb35598861c6b89524cb

Comment by Andrew Morrow (Inactive) [ 04/Jun/13 ]

Hi Dmitry -

That is certainly a possibility and we have discussed it internally, and we may in fact do something like that. But we did not want to delay fixing the build of the shared library behind that decision. We agree that the current situation with the SONAME is not ideal, but the lack of SONAME and the brokenness of the shared library build are separate issues. At least now there will actually be a shared library about which to complain about the lack of a SONAME!

Comment by Dmitry Konishchev [ 04/Jun/13 ]

But why don't set a soname to a number based on the current MongoDB version for now? Yeah, it's not very accurate but it eliminates crashes of user's software after MongoDB update and in my opinion worth it.

Comment by Andrew Morrow (Inactive) [ 04/Jun/13 ]

Hi Dmitry -

We evaluated adding a SONAME while working with the various patches that had been submitted for the driver shared library build, but we have decided against doing so at this time. Adding a SONAME would imply a level of ABI and API stability that, for various reasons, we are not yet comfortable enforcing.

We do intend to add a SONAME when we believe that we can do so in an accurate and useful fashion. That work will proceed under SERVER-1949.

Thanks,
Andrew

Comment by Dmitry Konishchev [ 04/Jun/13 ]

Please add a soname to this patch. At least like I've done it here - https://github.com/mongodb/mongo/pull/406/files#L0R26. Shared library without soname brings a lot of troubles when your services crash after update of MongoDB.

Comment by Andrew Morrow (Inactive) [ 04/Jun/13 ]

If building the shared client is to be a documented feature in 2.4.5, then we need to provide instructions on how to build it. Building from the C++ driver tarball is not (and will not be) a supported mechanism for building the shared client.

For 2.6, we are eliminating the separate driver tarball (see SERVER-9766), so there will be a separate documentation change required there.

Comment by auto [ 04/Jun/13 ]

Author:

{u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}

Message: SERVER-6514 Re-add support for building the C++ driver shared library
Branch: master
https://github.com/mongodb/mongo/commit/da8c0fa929eeb03dbe3fb0533874de31da0bc8c8

Comment by Dmitry Konishchev [ 17/May/13 ]

I would like to recommend https://github.com/mongodb/mongo/pull/406 pull request to resolve this issue because unlike the attached patch which fixes bug in old version of MongoDB and not applicable to MongoDB >= 2.4, this pull request fixes all issues that I've faced with while tried to use C++ driver's shared library:

  • Soname for C++ driver's shared library
  • two unneeded cpp files caused linker errors
  • gsasl was not linked against the lib when using --use-sasl-client and --sharedclient
  • Don't exclude assert macroses when building the client library - they are needed to build it, but will be successfully excluded then by undef_macros.h in dbclient.h
  • Added missing *.cpp files to the C++ driver's shared library
  • Added missing #include "mongo/util/assert_util.h"

Additionally:

  • All rules for building C++ driver that presented in mongo/SConscript have been moved to SConscript.client
  • Don't install duplicated client header files to /usr/include instead of /usr/include/mongo
Comment by Balint Szente [ 08/Mar/13 ]

Patch to fix the sharedclient generation for MongoDB version 2.2.x

Comment by Luca Marturana [ 25/Jan/13 ]

Are there any plans to solve this issue? What's the problem about building the shared library?

Generated at Thu Feb 08 03:11:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.