| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When interprocedural analysis is enabled on the IBMClang family of
compilers (via the `-flto` option) then the resulting object files
contain LLVM IR rather than XCOFF objects[1].
ExportImportList needs to detect LLVM IR objects and use the
`ibm-llvm-nm` tool that ships with the compiler to create the extract
the defined symbols.
Without this change, such objects result in an error message from
`dump` and no symbols being exported from the object file.
[1]: https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.0?topic=compatibility-link-time-optimization-lto
|
| |
|
|
|
|
|
|
|
|
| |
Since commit 0f150b69d3 (AIX: Explicitly compute shared object exports
for both XL and GNU, 2019-07-11, v3.16.0-rc1~418^2~2) we always export
all symbols from shared libraries by default. Add a new target property
called `AIX_EXPORT_ALL_SYMBOLS` that can be explicitly set to OFF to
suppress this behavior and export no symbols by default.
Fixes: #20290
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've long created shared objects on AIX using the linker's `-G` option
(also offered by the XL front-end). The `-G` option implies `-brtl` and
enables runtime linking. This has been largely unnecessary because we
provide all dependencies on the link line and both XL and GNU compilers
offer builtin behavior to export symbols. Since commit 0f150b69d3 (AIX:
Explicitly compute shared object exports for both XL and GNU,
2019-07-11) we compute exports explicitly and consistently.
Therefore runtime linking is no longer necessary for shared objects.
We've also long created executables on AIX using the linker's `-brtl`
option to enable runtime linking in case they load plugins at runtime.
Since commit 9f5c2040bf (AIX: Explicitly compute executable exports for
both XL and GNU, 2019-07-12) and commit 2fa920c0cd (AIX: Create import
library for executables with exports, 2019-07-16) we now provide the
linker enough information to fully resolve symbols in plugins up front.
Therefore runtime linking is no longer necessary for executables.
Drop use of `-G` for creating shared objects and use the XL `-qmkshrobj`
and GCC `-shared` options instead. Both invoke the linker with the
`-bM:SRE -bnoentry` options to create a shared object without runtime
linking enabled. Also drop use of `-brtl` for creating executables.
Issue: #19163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On AIX, symbols in shared objects must be exported in order to be
visible to dependents (similar to Windows). The AIX linker provides a
`-bE:...` option to specify a file listing symbols to be exported.
Compilers offer some features to help:
* When the XL compiler is invoked with its `-qmkshrobj`/`-G` options for
creating shared objects (without/with runtime linking), it recognizes
when no explicit `-bE:...` linker option is specified and runs a
`CreateExportList` tool provided with the compiler to compute one from
the object files. Since commit d468a2c2cb (XL: Avoid copying archives
into shared libraries that link them, 2011-04-07, v2.8.5~153^2) CMake
runs `CreateExportList` explicitly to ensure it only looks at the object
files and not any library files.
* When the GNU compiler is invoked with its `-shared` option for creating
shared objects, its internal `collect2` tool recognizes when no explicit
`-bE:...` linker option is specified and computes one itself from the
object files. However, it sometimes includes extra symbols such as
`.__init_aix_libgcc_cxa_atexit`.
Introduce our own internal `ExportImportList` script to compute symbol
export lists from object files. Use a basic implementation for now: it
can be extended as needed later. Update our shared library creation
rules to run the script explicitly for both the XL and GNU compilers.
Issue: #19163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We removed `-brtl` in commit bce7a2a3a5 (AIX: Do not use -brtl to create
shared libraries, 2013-03-11, v2.8.11~103^2~1) but it was added again by
commit f254276fc1 (AIX,HP-UX: Fix RPATH handling when CMP0065 is set to
NEW, 2015-12-11, v3.4.2~4^2). Since the latter commit we initialize the
`CMAKE_{SHARED,MODULE}_LINKER_FLAGS` to use the `-brtl` linker flag.
This is unnecessary because we already use the `-G` linker flag which
implies `-brtl`.
The latter commit also moved `-brtl` to `CMAKE_EXE_LINKER_FLAGS` from
flags that were always included in executable link lines with CMP0065
OLD behavior and are not part of the change intended by CMP0065. Leave
this for now as we've always enabled runtime linking for executables
(and implicitly done so via -G for shared libraries and modules).
Issue: #13997
Issue: #19163
|
| |
|
|
|
|
|
|
|
| |
Revise the logic from commit v3.7.0-rc1~173^2~2 (GNU: Do not use
-fvisibility on AIX or HP-UX, 2016-09-03) to add a version check.
The GCC 7 release notes [1] state that visibility support has been
added for AIX 7.1 and above.
[1] https://gcc.gnu.org/gcc-7/changes.html
|
| |
|
|
|
|
|
| |
Automate with:
find Modules -type f -print0 | xargs -0 perl -i -0pe \
's/set\(([a-zA-Z0-9_\$\{\}]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
|
| |
|
|
|
|
| |
Use of `-fvisibility=hidden` warns:
warning: visibility attribute not supported in this configuration; ignored
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document these variables.
Change our convention for setting these variables from:
set(CMAKE_EXE_LINKER_FLAGS_INIT "...")
to
string(APPEND CMAKE_EXE_LINKER_FLAGS_INIT " ...")
so that any value previously set by a toolchain file will be used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CMAKE_SHARED_LIBRARY_LINK_<LANG>_FLAGS setting has always been meant
for flags needed to export symbols from executables for use by shared
library plugins. Since commit v3.4.0-rc1~58^2~1 (CMP0065: Restrict the
use of CMAKE_SHARED_LIBRARY_LINK_<LANG>_FLAGS, 2015-08-24) this is made
explicit by using the flags only for executables with ENABLE_EXPORTS,
guarded by CMP0065 for compatibility.
On some platforms we were accidentally using this setting to pass other
flags to the linker:
* AIX: -bnoipath, -brtl
* HP-UX: +s, +nodefaultrpath
These flags are incorrectly dropped when CMP0065 is set to NEW. Fix
this by moving the flags to more appropriate places for linking
executables.
|
| |\
| |
| |
| |
| | |
bce7a2a AIX: Do not use -brtl to create shared libraries (#13997)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The flag was added incorrectly by commit 9c3a6eb4 (Need -brtl when creating
shared libraries, 2003-05-16). According to "man ld" the -G option implies
"-brtl -bnortllib ...", -brtl implies "-brtllib", and -brtllib should only be
used for executables, not shared libraries. Therefore it is incorrect and
unnecessary to specify -brtl explicitly after -G.
Reported-by: Kevin Burge <kcburge@gmail.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GNU compiler front-ends on AIX invoke the linker with flags of the
form "-L/path/to/gnu/runtime/lib" to tell ld where to find the language
runtime libraries. They depend on the default libpath behavior
documented in "man ld" to add the -L paths also to the runtime libpath
so the dynamic loader can find the language runtime libraries. This
differs from platforms whose linkers have distinct -rpath flags that
non-system compilers can use to tell the dynamic loader where to find
their language runtime libraries.
Since commit 96fd5909 (Implement linking with paths to library files,
2008-01-22) CMake always passes "-Wl,-blibpath:" followed by any
project-defined RPATH plus "/usr/lib:/lib" in order to explicitly set
the runtime libpath and avoid getting all the project -L paths in the
runtime libpath. The explicit libpath prevents the GNU compiler runtime
library -L paths from being placed in the libpath and then the dynamic
loader fails to find the language runtime libraries.
CMake already detects the implicit link directories for each language
since commit 07ea19ad (Implicit link info for C, CXX, and Fortran,
2009-07-23). Add the implicit link directories to the explicit runtime
libpath for GNU compilers on AIX to fix this use case.
|
| |
|
|
| |
We already use these flags with the XL toolchain. Use them for GNU too.
|
| |
|
|
|
|
| |
Move RPATH flags out of Platform/AIX.cmake into platform-specific
compiler information files Platform/AIX-XL and Platform/AIX-GNU.
The flags need to be set for each compiler of each language.
|
| | |
|
|
|
This moves GNU compiler flags into new-style modules
Compiler/GNU-<lang>.cmake
Platform/<os>-GNU-<lang>.cmake
We use language-independent helper modules
Compiler/GNU.cmake
Platform/<os>-GNU.cmake
to define macros consolidating the information.
|
