[SERVER-17567] Unconditional export of parseNumberFromStringWithBase Created: 12/Mar/15 Updated: 18/Sep/15 Resolved: 12/Mar/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.5, 3.1.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andrew Morrow (Inactive) | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Backport Completed: | |
| Steps To Reproduce: | Build on windows, then search the build directory for .exp and .lib files. |
| Participants: |
| Description |
|
On windows, it was observed that all executables were also producing a .lib and .exp file, even though no symbols should have been exported (e.g. from unit tests). Dumping the file showed that the exported symbols were specializations of mongo::parseNumberFromStringWtihBase. It appears that parseNumberFromStringWtihBase uses the unconditional export macro MONGO_COMPILER_API_EXPORT instead of the conditional MONGO_CLIENT_API macro, forcing the symbol to be exported and causing the generation of .lib and .exp files for all executables linking to the parse_number.obj file. Arguably, we should remove MONGO_CLIENT_API everywhere in the kernel now that the driver has diverged. Alternatively, we should just change this instance of MONGO_COMPILER_API_EXPORT to MONGO_CLIENT_API. |
| Comments |
| Comment by Githook User [ 10/Jul/15 ] |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}Message: (cherry picked from commit d8f3c2e618f69662d20ee684c9d8fe26ff3bace5) |
| Comment by Githook User [ 12/Mar/15 ] |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@mongodb.com'}Message: |