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

Unconditional export of parseNumberFromStringWithBase

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0.5, 3.1.0
    • Component/s: Internal Code
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Backport Completed:
    • Steps To Reproduce:
      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.

      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.

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: