summaryrefslogtreecommitdiff
path: root/Modules/CMakeParseImplicitLinkInfo.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMakeParseImplicitLinkInfo: Better detection of msvcRobert Maynard2022-09-021-1/+6
| | | | Use the compiler id information in addition to checking for `cl.exe`.
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-0/+4
| | | | | | | | | | | | | | | | | | | | | Divert LCC compiler as a new one, instead of treating it as GNU. Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been passing checks for GNU compilers, so it has been identified as GNU. Now, with intent of seriously upstreaming its support, it has been added as a separate LCC compiler, and its version displays not a supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead of GNU 7.3.0). This commit adds its support for detection, and also converts basically every check like 'is this compiler GNU?' to 'is this compiler GNU or LCC?'. The only places where this check is untouched, is where it regards other platforms where LCC is unavailable (primarily non-Linux), and where it REALLY differs from GNU compiler. Note: this transition may break software that are already ported to Elbrus, but hardly relies that LCC will be detected as GNU; still such software is not known.
* CMakeParseImplicitLinkInfo: Honor GNU static runtime library flagsBrad King2021-06-031-0/+32
| | | | | | | | With flags like `-static-libstdc++` or `-static-libgfortran`, the GNU compiler driver adds `-Bstatic ... -Bdynamic` around its language runtime library. Convert the libraries in between these to absolute paths so that mixed-language linking honors the static runtime libraries.
* CMakeDetermineCompilerABI: Extract lib arch from implicit object file pathsRobert Maynard2021-04-051-7/+42
| | | | | | | | | The NVHPC compiler does not have any implicit link directories that can be used to detect `CMAKE_LIBRARY_ARCHITECTURE`, but it does have implicit object files. Extract implicit object file paths from link lines and check them for the `CMAKE_LIBRARY_ARCHITECTURE` pattern. Issue: #22024
* CMakeParseImplicitLinkInfo supports comma separated link linesRobert Maynard2019-08-281-0/+12
| | | | | | | | | It is currently presumed that the linker will generate a space separated line. This is not the case for some compilers such as IBM XL where it can output space or comma separated. This is particularly apparent when IBM XL is used as the host compiler for CUDA as it generates a comma separated link line.
* Protect implicit link library extraction with policy CMP0054Brad King2018-07-101-0/+5
| | | | | | | | CMakeParseImplicitLinkInfo tests arbitrary content with `if(MATCHES)`. Set policy CMP0054 to ensure the line content is never interpreted as a variable reference (which may also produce a CMP0054 warning). While at it, also set policy CMP0053 to improve performance.
* Exclude "libgcc_eh" library files from implicit link librariesBrad King2018-04-161-1/+1
| | | | | | | | Extend the fix in commit v3.9.6~1^2 (Restore exclusion of "gcc_eh" from implicit link libraries, 2017-11-07) to also exclude `gcc_eh` libraries referenced by absolute path to the library file. Issue: #17436
* Restore exclusion of "gcc_eh" from implicit link librariesChristian Pfeiffer2017-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit v3.9.0-rc1~148^2 (Do not assume GCC libs are linked by all compilers, 2017-05-05) we no longer filter out all `gcc*` implicit link libraries. This allows mixing of gcc and non-gcc compilers across languages. However, this caused a subtle problem with how GCC makes exception handling symbols available to linked binaries. GCC (at least on MinGW) provides two different libraries with exception handling symbols: * gcc_s: A shared library with -fvisibility=default, used by -shared-libgcc. * gcc_eh: A static library with -fvisibility=hidden, used by -static-libgcc. The C compiler (on MinGW) defaults to -static-libgcc and uses gcc_eh. The C++ compiler defaults to -shared-libgcc and uses gcc_s when linking shared libraries and executables so that exceptions can propagate across shared libraries [1]. When linking a mixed-language binary, the C++ compiler should be used along with its choice of gcc_s. In this case gcc_eh should not be added even though the C compiler implies it because gcc_s supersedes it. Since the above-mentioned change, CMake is adding gcc_eh to C++ link lines that also contain C code on MinGW. This causes both gcc_s and gcc_eh to be used, which is incorrect. We can fix this simply by excluding gcc_eh from the C compiler's implicit link libraries. [1] https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Link-Options.html#Link-Options Fixes: #17436
* ImplicitLinkInfo: Add support for PGI on WindowsChristian Pfeiffer2017-05-201-4/+13
| | | | | | | Since PGI does not write linker directives into objects, the necessary libraries have to be parsed from commandline. PGI does however link the Visual C++ runtime libraries, so they have to be filtered out to ensure no collision with settings of other languages can occur.
* Do not assume GCC libs are linked by all compilersChristian Pfeiffer2017-05-051-1/+1
| | | | | Not all compilers link libgcc and libgcc_s causing trouble when linking C++ code with instance PGI Fortran and C compilers.
* separgs: Use NATIVE_COMMAND where appropriateChristian Pfeiffer2017-04-261-5/+1
|
* CMakeParseImplicitLinkInfo: Ignore ld -lto_library flagBrad King2017-04-031-1/+9
| | | | | | | The `ld` tool in Xcode 8.3 now has a `-lto_library <path>` flag. Ignore the flag instead of accidentally parsing it as `-l` with `to_library`. Fixes: #16766
* CMakeParseImplicitLinkInfo: Add support for MSVC invoked by CUDA nvccBrad King2017-01-121-0/+15
|
* Simplify CMake per-source license noticesBrad King2016-09-271-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 string(APPEND) in ModulesDaniel Pfeifer2016-07-281-22/+22
| | | | | | | 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'
* CMakeParseImplicitLinkInfo: Exclude libclang_rt librariesBrad King2016-07-111-1/+1
| | | | | | | | These libraries are used for Clang runtime analysis support with flags like `-fsanitize=memory` and are not actually implicitly linked libraries. Fixes #16194.
* CMakeParseImplicitLinkInfo: Exclude pathcc ldfe lines (#16100)Michał Górny2016-05-111-1/+1
| | | | | | PathScale uses a wrapper around the linker. The "ldfe" invocation in the output is followed by a normal "ld" invocation. Exclude the former so we can reach and parse the latter correctly.
* CMakeParseImplicitLinkInfo: Do not match "VAR=..." as link line (#15737)Brad King2015-09-111-1/+1
| | | | | | | | | | | | | | | When compiling with LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' the compiler output includes a line like COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' ... that our link line regex matches due to an argument ending in "-ld". Since it is not really the link line no implicit link information is dectected. Exclude "VAR=..." lines from consideration as link lines to fix this.
* CMakeParseImplicitLinkInfo: Avoid if() auto-deref in quoted argBrad King2015-02-181-1/+1
| | | | | | When matching implicit library names, use a sentinel "x" to avoid ever expanding the library name as a variable. This was detected by a CMP0054 warning.
* CMakeParseImplicitLinkInfo: Fix implicit library loggingBrad King2014-12-011-1/+2
| | | | | | | | | | In commit v3.1.0-rc1~640^2~5 (Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex), 2014-04-06) we accidentally broke logging of the implicit library detection. Restore use of the intermediate 'lib' variable so that the log message is constructed properly. Reported-by: Bill Somerville <bill@classdesign.com>
* Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex)Rolf Eike Beer2014-04-141-6/+4
| | | | | | The matches have already been calculated and can simply be taken from CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very similar regular expressions.
* Sanitize linker name to parse implicit link line (#14154)Brad King2013-05-171-0/+1
| | | | | | | | Teach CMakeParseImplicitLinkInfo to convert the CMAKE_LINKER file name to a regular expression that matches only the original name. Escape special characters like '+' so they are not treated as regex syntax. Extend the ImplicitLinkInfoTest to test handling of a CMAKE_LINKER value with many special characters.
* Recognize ld with toolchain prefix (#13960)Brad King2013-05-061-1/+1
| | | | | Teach CMAKE_PARSE_IMPLICIT_LINK_INFO to recognize linker invocations of the form "<toolchain-prefix>-ld" e.g. "x86_64-pc-linux-gnu-ld".
* Merge topic 'implicit-lib-canonical-path'Brad King2013-02-081-0/+6
|\ | | | | | | | | 10e8b2d Normalize full paths in implicit link library list
| * Normalize full paths in implicit link library listBrad King2013-02-061-0/+6
| | | | | | | | | | | | | | | | | | | | Teach CMakeParseImplicitLinkInfo to convert implicit link library full paths to a canonical form. This makes them more reproducible in case different language compiler front-ends add the same library by different paths e.g. ".../libA.a" and "...//libA.a". Add a case to the CMake.ImplicitLinkInfo test to cover removal of extra slashes from both library and directory paths.
* | OS X: Detect implicit linker framework search pathsBrad King2012-12-111-14/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we hard-coded a list of implicit framework directories but did not account for CMAKE_OSX_SYSROOT or for changes to the list across OS X versions. Instead we should automatically detect the framework directories for the active toolchain. The parent commit added the "-Wl,-v" option to ask "ld" to print its implicit directories. It displays a block such as: Framework search paths: /... Parse this block to extract the list of framework directories. Detection may fail on toolchains that do not list their framework directories, such as older OS X linkers. Always treat the paths <sdk>/Library/Frameworks <sdk>/System/Library/Frameworks <sdk>/Network/Library/Frameworks # Older OS X only /System/Library/Frameworks as implicit. Note that /System/Library/Frameworks should always be considered implicit so that frameworks CMake finds there will not override the SDK copies.
* | OS X: Detect implicit link directories on modern toolchainsBrad King2012-12-111-3/+26
|/ | | | | | | | | | | | | | | | | | | | | | | | | We detect the implicit link directories for the toolchain by adding a flag to get verbose output from the compiler front-end while linking the ABI detection binary. Newer OS X toolchains based on Clang do not add the implicit link directories with -L options to their internal invocation of "ld". Instead they use a linker that comes with the toolchain and is already configured with the proper directories. Add the "-Wl,-v" option to ask "ld" to print its implicit directories. It displays them in a block such as: Library search paths: /... Parse this block to extract the implicit link directories. While at it, remove the checks introduced by commit efaf335b (Skip implicit link information on Xcode, 2009-07-23) and commit 5195a664 (Skip implicit link info for multiple OS X archs, 2009-09-22). Discard the non-system link directories added by Xcode. Discard all detected implicit libraries in the multi-architecture case but keep the directories. The directories are still useful without the libraries just to suppress addition of explicit -L options for them.
* Absoft: Detect implicit link libraries on Linux and MacBrad King2011-05-201-3/+5
| | | | | | | | Use the "-X -v" flag to the Absoft front-end to pass "-v" to the gcc it invokes under the hood. Teach CMakeParseImplicitLinkInfo to exclude linker version lines from consideration as link lines. Fix parsing of Sun's linker search path option "-Y..." to avoid conflict with the Mac linker option "-Y<num>".
* Detect object files in implicit link informationBrad King2010-12-091-1/+6
| | | | | | The NAG Fortran compiler implicitly passes object files by full path to the linker. Teach CMakeParseImplicitLinkInfo to parse object files that match some tool-specific regular expression.
* Modules: Fix spelling 'To distributed' -> 'To distribute'Todd Gamblin2010-08-091-1/+1
|
* Remove non-language implicit link dependenciesBrad King2009-11-051-5/+16
| | | | | | | | | | | | | | | | Some compilers use implicit link options of the form -lcrt*.o -lgcc* -lSystem (on Mac) -lSystemStubs (on Mac) that provide system-wide symbols not specific to any language. These need not be listed explicitly for mixed-language linking. We teach CMake to remove the above items from the implicit library list of each language. This change makes it possible to mix GNU compiler versions in some cases.
* More robust implicit link line detection regexBrad King2009-10-071-1/+3
| | | | | | | | The regex used by CMAKE_PARSE_IMPLICIT_LINK_INFO to detect link lines should not match lines that happen to have ".../ld.../..." in them. A linker name should match only as the last component of a path. See issue #9666.
* Log implicit link line detection regexBrad King2009-10-061-0/+1
| | | | | | | | | | This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log the regex it uses to detect the linker invocation line. The regex is computed from the CMAKE_LINKER if it is found, so it might change. A strange value might match the wrong line and cause implicit link info extraction to fail. See issue #9666.
* Log implicit link information parsing actionsBrad King2009-10-061-1/+21
| | | | | | | This commit teaches the CMAKE_PARSE_IMPLICIT_LINK_INFO function to log its actions. We store the log in CMakeFiles/CMakeOutput.log at the top of the project build tree. This will make diagnosis of implicit link information parsing problems easier.
* Convert CMake non-find modules to BSD LicenseBrad King2009-09-281-0/+13
| | | | | | | This adds copyright/license notification blocks CMake's non-find modules. Most of the modules had no notices at all. Some had notices referring to the BSD license already. This commit normalizes existing notices and adds missing notices.
* Recognize linker commands without pathsBrad King2009-07-291-1/+1
| | | | | | | This teaches the implicit link line parsing code to recognize link lines that do not have a full path to the linker executable. At least one version of the Intel compiler on Linux invokes the linker as just "ld" instead of "/usr/bin/ld".
* BUG: Parse implicit link editor -z*extract optionsBrad King2009-07-281-1/+4
| | | | | | | | The Sun Fortran compiler passes -zallextract and -zdefaultextract to the linker so that all objects from one of its archives are included in the link. This teaches the implicit options parser to recognize the flags. We need to pass them explicitly on C++ link lines when Fortran code is linked.
* ENH: Implicit link info for C, CXX, and FortranBrad King2009-07-231-0/+71
This teaches CMake to detect implicit link information for C, C++, and Fortran compilers. We detect the implicit linker search directories and implicit linker options for UNIX-like environments using verbose output from compiler front-ends. We store results in new variables called CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES The implicit libraries can contain linker flags as well as library names.
View Lorry Controller Status