1. 16 Jul, 2019 1 commit
    • Brad King's avatar
      AIX: Create import library for executables with exports · 2fa920c0
      Brad King authored
      On AIX, plugins meant to be loaded into executables via `dlopen` must be
      linked with access to a list of symbols exported from the executable in
      order to use them (when not using runtime linking).  The AIX linker
      supports specifying this list as an "import file" passed on the command
      line either via the `-bI:...` option or (with a leading `#! .` line) as
      a normal input file like any other library file.
      
      The linker import file plays the same role on AIX as import libraries do
      on Windows.  Teach CMake to enable its import library abstraction on AIX
      for executables with the `ENABLE_EXPORTS` target property set.  Teach
      our internal `ExportImportList` script to optionally generate a leading
      `#! .` line at the top of the generated export/import list.  Update our
      rule for linking an executable with exports to generate a public-facing
      "import library" implemented as an AIX linker import file.
      
      With this approach, our existing infrastructure for handling import
      libraries on Windows will now work for AIX linker import files too:
      
      * Plugins that link to their executable's symbols will be automatically
        linked using the import file on the command line.
      
      * The executable's import file will be (optionally) installed and
        exported for use in linking externally-built plugins.
      
      This will allow executables and their plugins to build even if we later
      turn off runtime linking.
      
      Issue: #19163
      2fa920c0
  2. 15 Jul, 2019 1 commit
    • Brad King's avatar
      AIX: Explicitly compute executable exports for both XL and GNU · 9f5c2040
      Brad King authored
      On AIX, symbols in executables must be exported in order to be visible
      to modules (plugins) they load via `dlopen`.  Prior to policy `CMP0065`,
      CMake linked all executables with flags to export symbols, but the NEW
      behavior for that policy is to do so only for executables that have the
      `ENABLE_EXPORTS` target property set.  In both cases, CMake has always
      used the AIX linker option `-bexpall` option to export symbols from
      executables.
      
      This has worked fairly well with the XL compiler, but with the GNU
      compiler it works only for C ABI symbols.  The reason is that `-bexpall`
      does not export symbols starting in `_` but the GNU C++ ABI mangles all
      symbols with a leading `_`.  Therefore we have only supported C ABI
      plugins with the GNU compiler on AIX.  Some projects have tried to work
      around this by replacing `-bexpall` with `-bexpfull`, but the latter
      often exports symbols that we do not want exported.
      
      Avoid using `-bexpall` for executables by instead using by our own
      internal `ExportImportList` script to compute symbol export lists from
      the object files to be linked into an executable.  Pass the explicitly
      computed export list to the AIX linker's `-bE:...` option.  We already
      do this for shared object exports.
      
      Issue: #19163
      9f5c2040
  3. 14 Jul, 2019 1 commit
  4. 12 Jul, 2019 1 commit
  5. 04 Jun, 2019 2 commits
  6. 23 May, 2019 1 commit
  7. 21 May, 2019 1 commit
  8. 16 May, 2019 1 commit
  9. 14 May, 2019 1 commit
  10. 17 Apr, 2019 1 commit
    • Brad King's avatar
      MSVC: Add abstraction for runtime library selection · fb3370b6
      Brad King authored
      Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
      abstraction to select the runtime library from an enumeration of logical
      names.  We've long hesitated to do this because the idea of "runtime
      library selection" touches on related concepts on several platforms.
      Avoid that scope creep by simply defining an abstraction that applies
      only when targeting the MSVC ABI on Windows.
      
      Removing the old default flags requires a policy because existing
      projects may rely on string processing to edit them and choose a runtime
      library under the old behavior.  Add policy CMP0091 to provide
      compatibility.
      
      Fixes: #19108
      fb3370b6
  11. 31 Mar, 2019 1 commit
  12. 23 Mar, 2019 20 commits
  13. 21 Mar, 2019 3 commits
  14. 21 Feb, 2019 1 commit
  15. 15 Feb, 2019 1 commit
  16. 07 Feb, 2019 1 commit
  17. 27 Jan, 2019 1 commit
  18. 18 Jan, 2019 1 commit