maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/darwin-ld-lto.c

20 lines
732 B
C
Raw Normal View History

[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
// REQUIRES: system-darwin
darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a dependency happens to contain bitcode, ld64 will try to load libLTO without -flto explicitly being enabled. However, the change had the undesirable side effect of warning if libLTO.dylib doesn't exist even if it isn't needed. Change things so that -lto_library is always passes, independent of if it exists or not. ld64 only looks at this flag if it uses LTO. If the dylib exists, all is well. If it doesn't, and LTO is not being used, all is well too. If ld64 does end up using LTO and the dylib does not exist, ld64 will print something like ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64 https://reviews.llvm.org/D26984 llvm-svn: 287685
2016-11-23 03:38:07 +08:00
// Check that ld gets "-lto_library".
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
[test] Pass a fake libLTO.dylib to a driver test which depends on it This makes it possible to run 'check-clang' on Darwin without building libLTO.dylib. See r280142 for more context. llvm-svn: 280150
2016-08-31 04:36:50 +08:00
// RUN: mkdir -p %T/bin
// RUN: mkdir -p %T/lib
// RUN: touch %T/lib/libLTO.dylib
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -### %s \
Unconditionally pass `-lto_library` to the linker on Darwin We're only doing it with -flto currently, however it never "hurt" to pass it, and users that are linking without -flto can get in trouble if one of the dependency (a static library for instance) contains bitcode. Differential Revision: https://reviews.llvm.org/D25932 llvm-svn: 285254
2016-10-27 07:23:08 +08:00
// RUN: -ccc-install-dir %T/bin -mlinker-version=133 2> %t.log
[test] Pass a fake libLTO.dylib to a driver test which depends on it This makes it possible to run 'check-clang' on Darwin without building libLTO.dylib. See r280142 for more context. llvm-svn: 280150
2016-08-31 04:36:50 +08:00
// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH %s -input-file %t.log
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
//
// LINK_LTOLIB_PATH: {{ld(.exe)?"}}
// LINK_LTOLIB_PATH: "-lto_library"
darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a dependency happens to contain bitcode, ld64 will try to load libLTO without -flto explicitly being enabled. However, the change had the undesirable side effect of warning if libLTO.dylib doesn't exist even if it isn't needed. Change things so that -lto_library is always passes, independent of if it exists or not. ld64 only looks at this flag if it uses LTO. If the dylib exists, all is well. If it doesn't, and LTO is not being used, all is well too. If ld64 does end up using LTO and the dylib does not exist, ld64 will print something like ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64 https://reviews.llvm.org/D26984 llvm-svn: 287685
2016-11-23 03:38:07 +08:00
// Also pass -lto_library even if the file doesn't exist; if it's needed at
// link time, ld will complain instead.
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -### %s \
Unconditionally pass `-lto_library` to the linker on Darwin We're only doing it with -flto currently, however it never "hurt" to pass it, and users that are linking without -flto can get in trouble if one of the dependency (a static library for instance) contains bitcode. Differential Revision: https://reviews.llvm.org/D25932 llvm-svn: 285254
2016-10-27 07:23:08 +08:00
// RUN: -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a dependency happens to contain bitcode, ld64 will try to load libLTO without -flto explicitly being enabled. However, the change had the undesirable side effect of warning if libLTO.dylib doesn't exist even if it isn't needed. Change things so that -lto_library is always passes, independent of if it exists or not. ld64 only looks at this flag if it uses LTO. If the dylib exists, all is well. If it doesn't, and LTO is not being used, all is well too. If ld64 does end up using LTO and the dylib does not exist, ld64 will print something like ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64 https://reviews.llvm.org/D26984 llvm-svn: 287685
2016-11-23 03:38:07 +08:00
// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH %s -input-file %t.log