[SERVER-10053] File processinfo_darwin.cpp missing from mongo-cxx-driver Created: 28/Jun/13 Updated: 11/Jul/16 Resolved: 03/Jul/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client |
| Affects Version/s: | 2.4.4, 2.5.0 |
| Fix Version/s: | 2.4.6, 2.5.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Raul Guerrero | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
any Mac OS X version |
||
| Operating System: | ALL |
| Steps To Reproduce: | 1) Download the tarball from: http://downloads.mongodb.org/cxx-driver/mongodb-linux-x86_64-latest.tgz (dated 2013-06-20 06:07:57) 2) Run scons |
| Participants: |
| Description |
|
When running scons to build the mongo C++ driver from: http://downloads.mongodb.org/cxx-driver/mongodb-linux-x86_64-latest.tgz (dated 2013-06-20 06:07:57) I get the error: scons: *** [build/mongo/util/processinfo_darwin.o] Source `src/mongo/util/processinfo_darwin.cpp' not found, needed by target `build/mongo/util/processinfo_darwin.o'. The file is missing from the tarball, I went into github and searched the file from the mongo source, downloaded and copied the file and it seems to work now, I just get the following found no symbols messages at the end of the build: /usr/bin/ranlib: file: build/libmongoclient.a(ssl_manager.o) has no symbols |
| Comments |
| Comment by auto [ 03/Jul/13 ] | |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |
| Comment by Raul Guerrero [ 01/Jul/13 ] | |
|
Here's an example of all the hoops you have to jump through just to build the C++ driver for windows: That's the kind of thing that would be great to improve, according to that tutorial, you have to build mongo, then the driver, and before that install a whole bunch of stuff. What would be great is just to have a visual studio project file, open it or run devenv from the command prompt, and build it, instead of depending on python, python extensions, scons, a special version of Boost or else it breaks if you use newer ones etc. | |
| Comment by Raul Guerrero [ 01/Jul/13 ] | |
|
Hi Andrew, Well, the advantages of having a separate way of building the driver are: Those are a couple that pop into my mind. Also, it would be even better to have project files for the native development environments for at least Windows and Mac, so people not only build the drivers and server easier, but also it would really help for code contributions, as you would only have to open your project file in your usual IDE and that's it, at least include a Visual Studio (VS 2012 or VS 2010) and XCode project files, that would be great. I know you guys use scons for your build system and Boost as your libraries, it's not as easy to have the environment setup, mostly on Windows that could be an issue, and using brew on the Mac can be cumbersome because having to use specific versions of Boost, and handling that can also be a bit complicated. | |
| Comment by Andrew Morrow (Inactive) [ 30/Jun/13 ] | |
|
Hi Raul - I'm glad it is working better for you now. Regarding Windows client builds from the driver tarball: I haven't really looked into what will be necessary to make this work, but May I ask what you consider to be the advantages to using the C++ client tarball over the whole repo method? I'd like to better understand why developers using the C++ driver prefer one build method or the other, since in theory the resulting build artifacts are the same. Thanks, | |
| Comment by Raul Guerrero [ 30/Jun/13 ] | |
|
awesome, I downloaded the latest from http://downloads.mongodb.org/cxx-driver/mongodb-linux-x86_64-latest.tgz (dated 2013-06-30) and it compiled without issues now. Do you guys think there's a way of compiling this driver only tarball on Windows? or if there's some alternative to doing that? (we're using VS2012 as we're using C++ 11 language features) | |
| Comment by Andrew Morrow (Inactive) [ 29/Jun/13 ] | |
|
Raul - The relevant nightly build has pushed an updated client driver tarball containing a potential fix. Can you confirm that it fixes this issue for you? | |
| Comment by Andrew Morrow (Inactive) [ 28/Jun/13 ] | |
|
Needs to be backported to 2.4 | |
| Comment by Andrew Morrow (Inactive) [ 28/Jun/13 ] | |
|
Hi Raul - I've just pushed a fix to master for this issue, so the next pushed nightly client tarball should work better for you. If you do test it, please update this ticket with your results. After this burns in on master for a bit and seems good I'll get it backported to 2.4. | |
| Comment by auto [ 28/Jun/13 ] | |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: | |
| Comment by Raul Guerrero [ 28/Jun/13 ] | |
|
Thanks for the ticket link Andrew, actually it wasn't that useful as there weren't much instructions on how to do the build (or at least I didn't understand them), but I found this link http://grokbase.com/t/gg/mongodb-user/128tmfjfdj/how-i-installed-the-windows-7-64x-c-driver-mongodb-to-work-with-visual-studio-2010 which shows how to build it under VS 2010, I just did a couple of adaptations to use VS 2012 and Boost 1.53 instead of 1.45 like the tutorial suggests, but it worked like a charm. I hope you guys find a way to really simplify the build on Windows for the C++ driver, as all the steps needed are a mess and very error prone, I hope someday building it is as easy as it is on linux or the mac. Thanks! | |
| Comment by Andrew Morrow (Inactive) [ 28/Jun/13 ] | |
|
There is a ticket about building the driver from the source tarball on Windows: | |
| Comment by Raul Guerrero [ 28/Jun/13 ] | |
|
Thanks Andrew, I will try using the -use-system-all flag, actually I didn't use it before, so I'm almost sure that is the case you mention that it's building everything inside the static library. But still, I think it would be good to have a separate way of building the client driver without having to get the full mongo source. I also still need to have the same working on Windows, which I haven't even been able to build the library, but that's something outside the scope of this bug. Thanks | |
| Comment by Andrew Morrow (Inactive) [ 28/Jun/13 ] | |
|
I don't know for sure, but perhaps when you built the driver from the full source tree that you did not pass --use-system-all, which means that the driver will statically link in a great deal of code from mongo's internal copies of things like boost, which you almost certainly don't want. I'd give it another try with --use-system-all and see if you get better results that way. | |
| Comment by Eric Milkie [ 28/Jun/13 ] | |
|
Regarding ssl_manager.o: if you build without --ssl, that file will compile down to no exported symbols. Ideally the build could handle this situation differently, but for now the warning message you currently get is innocuous. | |
| Comment by Raul Guerrero [ 28/Jun/13 ] | |
|
Hi, thanks for the workaround, I've read about getting the full source and building the client before, but I've had issues doing that, I don't know why, but the client driver size went up to 150MB, it was just WAY to big, so I've decided to try to build the client from the tarball, and try to figure out a workaround to any issues. By just copying the missing file it was able to build, and now the library is only 4MB, but I don't know how it could affect the missing symbols part: Do you think that it could cause me any unexpected problems? Also, I do use brew for getting both boost and scons, that's how I got it to build the client driver from the tarball | |
| Comment by Andrew Morrow (Inactive) [ 28/Jun/13 ] | |
|
Hi - Thank you for the bug report. One thing to note is that you can work around this issue by building the client driver from the complete mongo source tree, rather than from the client tarball. To build this way:
Building from the full source checks for the availability of several software packages that are not actually required to build the driver, so you may also need to install these libraries to get the configure stage to succeed. |