summaryrefslogtreecommitdiffstats
path: root/Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Exclude "libgcc_eh" library files from implicit link librariesBrad King2018-04-161-0/+6
| | | | | | | | 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/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+48
| | | | | | | 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-30/+30
| | | | | Not all compilers link libgcc and libgcc_s causing trouble when linking C++ code with instance PGI Fortran and C compilers.
* CMakeParseImplicitLinkInfo: Ignore ld -lto_library flagBrad King2017-04-031-0/+6
| | | | | | | 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/+7
|
* CMakeParseImplicitLinkInfo: Exclude libclang_rt librariesBrad King2016-07-111-0/+6
| | | | | | | | These libraries are used for Clang runtime analysis support with flags like `-fsanitize=memory` and are not actually implicitly linked libraries. Fixes #16194.
* CMakeParseImplicitLinkInfo: Do not match "VAR=..." as link line (#15737)Brad King2015-09-111-0/+7
| | | | | | | | | | | | | | | 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.
* 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.
* 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-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+97
|/ | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+15
| | | | | | | | 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/+8
| | | | | | 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.
* Check Mac linker lines in ImplicitLinkInfo testBrad King2009-11-051-0/+33
| | | | We add sample linker invocation lines for the GNU compiler on Mac.
* Remove non-language implicit link dependenciesBrad King2009-11-051-15/+15
| | | | | | | | | | | | | | | | 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-0/+8
| | | | | | | | 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 information parsing actionsBrad King2009-10-061-1/+3
| | | | | | | 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.
* Check PGI linker lines in ImplicitLinkInfo testBrad King2009-07-291-0/+18
| | | | This adds sample linker invocation lines for the PGI compiler on Linux.
* Check Intel linker lines in ImplicitLinkInfo testBrad King2009-07-291-0/+18
| | | | | | This adds sample linker invocation lines for the Intel compiler on Linux. In particular, this exercises the case when "ld" appears without a full path.
* BUG: Parse implicit link editor -z*extract optionsBrad King2009-07-281-2/+2
| | | | | | | | 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.
* BUG: Further avoid ImplicitLinkInfo case changeBrad King2009-07-251-6/+6
| | | | | | The commit "Avoid case change in ImplicitLinkInfo test" did not change all of the paths to mingw, so some case change still occurs. This changes more of them.
* BUG: Avoid case change in ImplicitLinkInfo testBrad King2009-07-241-6/+6
| | | | | | Since "get_filename_component(... ABSOLUTE)" retrieves the actual case for existing paths on windows, we need to use an obscure path for mingw. Otherwise the test can fail just because the case of the paths changes.
* ENH: Create ImplicitLinkInfo testBrad King2009-07-231-0/+319
This tests the internal CMakeParseImplicitLinkInfo.cmake module to ensure that implicit link information is extracted correctly. The test contains many manually verified examples from a variety of systems.
generated by cgit v0.12 at 2025-01-06 12:44:25 (GMT)