Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-17567

Unconditional export of parseNumberFromStringWithBase

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.0.5, 3.1.0
    • Affects Version/s: None
    • Component/s: Internal Code
    • None
    • Fully Compatible
    • ALL
    • Hide

      Build on windows, then search the build directory for .exp and .lib files.

      Show
      Build on windows, then search the build directory for .exp and .lib files.
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            andrew.morrow@mongodb.com Andrew Morrow (Inactive)
            Reporter:
            andrew.morrow@mongodb.com Andrew Morrow (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved:
              None
              None
              None
              None