[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
scons --sharedclient mongoclient |
| Comments |
| Comment by Ultrabug [ 28/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Thx a bunch Johan & Andrew. | |||||||||||||||||||||||||||||||||||||||||||
| Comment by Johan Hedin [ 27/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
acm, Ultrabug here you go: | |||||||||||||||||||||||||||||||||||||||||||
| 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, | |||||||||||||||||||||||||||||||||||||||||||
| 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:
I can't explain why though I build mongodb 2.4.3 and 2.4.4 inside a RPM with the following arguments:
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:
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:
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: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 07/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 07/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 07/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 07/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| 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:
| |||||||||||||||||||||||||||||||||||||||||||
| 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:
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. 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.
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 As for the --sharedclient issue, we also have to patch this way (also for new SASL2 support) 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 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. 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. | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 06/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 06/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| 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 ] | |||||||||||||||||||||||||||||||||||||||||||
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: SHLINKFLAGS are not added to the compile command line, but LINKFLAGS are, and without " (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, | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 05/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 05/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 05/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| 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/
I don't have boost_thread-mt but I do have boost_thread in extrapath/lib. I found that
has disappeared from the compilation test command line with the two cherrypicks.
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:
I found the issue in this code added by 5316bea8 in src/SConscript.client:160:
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: | |||||||||||||||||||||||||||||||||||||||||||
| 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: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 04/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: Primarily a backport of da8c0fa929eeb03dbe3fb0533874de31da0bc8c8, with 680f0bf57260bf020cfaeb35598861c6b89524cb | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 04/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: Primarily a backport of da8c0fa929eeb03dbe3fb0533874de31da0bc8c8, with 680f0bf57260bf020cfaeb35598861c6b89524cb | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 04/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 04/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 04/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| 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 Thanks, | |||||||||||||||||||||||||||||||||||||||||||
| 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 | |||||||||||||||||||||||||||||||||||||||||||
| Comment by auto [ 04/Jun/13 ] | |||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |||||||||||||||||||||||||||||||||||||||||||
| 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:
Additionally:
| |||||||||||||||||||||||||||||||||||||||||||
| 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? |