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/cross-linux.c

104 lines
7.2 KiB
C
Raw Normal View History

Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_cross_linux_tree/usr \
// RUN: --target=i386-unknown-linux-gnu \
// RUN: | FileCheck --check-prefix=CHECK-I386 %s
// CHECK-I386: "-cc1" "-triple" "i386-unknown-linux-gnu"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-I386: "{{.*}}/Inputs/basic_cross_linux_tree/usr/lib/gcc/i386-unknown-linux-gnu/4.6.0/../../../../i386-unknown-linux-gnu/bin{{/|\\\\}}as" "--32"
// CHECK-I386: "{{.*}}/Inputs/basic_cross_linux_tree/usr/lib/gcc/i386-unknown-linux-gnu/4.6.0/../../../../i386-unknown-linux-gnu/bin{{/|\\\\}}ld" {{.*}} "-m" "elf_i386"
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_cross_linux_tree/usr \
// RUN: --target=x86_64-unknown-linux-gnu \
// RUN: | FileCheck --check-prefix=CHECK-X86-64 %s
// CHECK-X86-64: "-cc1" "-triple" "x86_64-unknown-linux-gnu"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-X86-64: "{{.*}}/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin{{/|\\\\}}as" "--64"
// CHECK-X86-64: "{{.*}}/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin{{/|\\\\}}ld" {{.*}} "-m" "elf_x86_64"
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_cross_linux_tree/usr \
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// RUN: --target=x86_64-unknown-linux-gnux32 \
// RUN: | FileCheck --check-prefix=CHECK-X32 %s
// CHECK-X32: "-cc1" "-triple" "x86_64-unknown-linux-gnux32"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-X32: "{{.*}}/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin{{/|\\\\}}as" "--x32"
// CHECK-X32: "{{.*}}/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin{{/|\\\\}}ld" {{.*}} "-m" "elf32_x86_64"
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_cross_linux_tree/usr \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --target=x86_64-unknown-linux-gnu -m32 \
// RUN: | FileCheck --check-prefix=CHECK-I386 %s
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --gcc-toolchain=%S/Inputs/basic_cross_linux_tree/usr \
// RUN: --target=i386-unknown-linux-gnu -m64 \
// RUN: | FileCheck --check-prefix=CHECK-X86-64 %s
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_32bit_linux_tree/usr \
// RUN: --target=i386-unknown-linux \
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MULTI32-I386 %s
// CHECK-MULTI32-I386: "-cc1" "-triple" "i386-unknown-linux"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-MULTI32-I386: "{{.*}}/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/bin{{/|\\\\}}as" "--32"
// CHECK-MULTI32-I386: "{{.*}}/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/bin{{/|\\\\}}ld"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI32-I386: "--sysroot=[[sysroot:.*/Inputs/basic_linux_tree]]"
// CHECK-MULTI32-I386: "-m" "elf_i386"
With help from chapuni on IRC, I think this is right now. =] The issue is that the command is quoted differently from the arguments. The command has '\' and the argument has '\\'. This is made unclear because FileCheck escapes the single matched '\' when it prints the contents of the variable, thus fooling me into thinking it had matched '\\' as intended. The solution is to bind the gcc_install variable in the argument list rather than out of the command. To do so we also have to be a bit more careful so that we don't get stray other things into the '.*' regex. Also, because of the argument difference, '\\\\' is the correct formulation before crtbegin, go back to that. llvm-svn: 187489
2013-07-31 19:14:13 +08:00
// CHECK-MULTI32-I386: "crti.o" "[[gcc_install:.*/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0]]{{/|\\\\}}crtbegin.o"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI32-I386: "-L[[gcc_install]]"
Revert "Support cross linking to arm on ubuntu." This reverts commit r193528 (and fixes). It broke Chandler's setup. llvm-svn: 193554
2013-10-29 07:14:34 +08:00
// CHECK-MULTI32-I386: "-L[[gcc_install]]/../../../../i386-unknown-linux/lib/../lib32"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI32-I386: "-L[[gcc_install]]/../../../../i386-unknown-linux/lib"
// CHECK-MULTI32-I386: "-L[[sysroot]]/lib"
// CHECK-MULTI32-I386: "-L[[sysroot]]/usr/lib"
Add and tighten up tests for cross compiling tool selection. This now verifies that we run the assembler and linker in the correct mode, and that we can successfully use a bi-arch variant of a GCC installation in a generic cross compilation invocation of Clang. llvm-svn: 184662
2013-06-23 16:24:15 +08:00
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Add and tighten up tests for cross compiling tool selection. This now verifies that we run the assembler and linker in the correct mode, and that we can successfully use a bi-arch variant of a GCC installation in a generic cross compilation invocation of Clang. llvm-svn: 184662
2013-06-23 16:24:15 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_32bit_linux_tree/usr \
// RUN: --target=x86_64-unknown-linux \
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
Add and tighten up tests for cross compiling tool selection. This now verifies that we run the assembler and linker in the correct mode, and that we can successfully use a bi-arch variant of a GCC installation in a generic cross compilation invocation of Clang. llvm-svn: 184662
2013-06-23 16:24:15 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MULTI32-X86-64 %s
// CHECK-MULTI32-X86-64: "-cc1" "-triple" "x86_64-unknown-linux"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-MULTI32-X86-64: "{{.*}}/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/bin{{/|\\\\}}as" "--64"
// CHECK-MULTI32-X86-64: "{{.*}}/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/bin{{/|\\\\}}ld"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI32-X86-64: "--sysroot=[[sysroot:.*/Inputs/basic_linux_tree]]"
// CHECK-MULTI32-X86-64: "-m" "elf_x86_64"
With help from chapuni on IRC, I think this is right now. =] The issue is that the command is quoted differently from the arguments. The command has '\' and the argument has '\\'. This is made unclear because FileCheck escapes the single matched '\' when it prints the contents of the variable, thus fooling me into thinking it had matched '\\' as intended. The solution is to bind the gcc_install variable in the argument list rather than out of the command. To do so we also have to be a bit more careful so that we don't get stray other things into the '.*' regex. Also, because of the argument difference, '\\\\' is the correct formulation before crtbegin, go back to that. llvm-svn: 187489
2013-07-31 19:14:13 +08:00
// CHECK-MULTI32-X86-64: "crti.o" "[[gcc_install:.*/Inputs/multilib_32bit_linux_tree/usr/lib/gcc/i386-unknown-linux/4.6.0]]/64{{/|\\\\}}crtbegin.o"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI32-X86-64: "-L[[gcc_install]]/64"
// CHECK-MULTI32-X86-64: "-L[[gcc_install]]/../../../../i386-unknown-linux/lib/../lib64"
// CHECK-MULTI32-X86-64: "-L[[gcc_install]]"
// CHECK-MULTI32-X86-64: "-L[[gcc_install]]/../../../../i386-unknown-linux/lib"
// CHECK-MULTI32-X86-64: "-L[[sysroot]]/lib"
// CHECK-MULTI32-X86-64: "-L[[sysroot]]/usr/lib"
Add and tighten up tests for cross compiling tool selection. This now verifies that we run the assembler and linker in the correct mode, and that we can successfully use a bi-arch variant of a GCC installation in a generic cross compilation invocation of Clang. llvm-svn: 184662
2013-06-23 16:24:15 +08:00
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Add and tighten up tests for cross compiling tool selection. This now verifies that we run the assembler and linker in the correct mode, and that we can successfully use a bi-arch variant of a GCC installation in a generic cross compilation invocation of Clang. llvm-svn: 184662
2013-06-23 16:24:15 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_64bit_linux_tree/usr \
// RUN: --target=i386-unknown-linux \
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
Add and tighten up tests for cross compiling tool selection. This now verifies that we run the assembler and linker in the correct mode, and that we can successfully use a bi-arch variant of a GCC installation in a generic cross compilation invocation of Clang. llvm-svn: 184662
2013-06-23 16:24:15 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MULTI64-I386 %s
// CHECK-MULTI64-I386: "-cc1" "-triple" "i386-unknown-linux"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-MULTI64-I386: "{{.*}}/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/bin{{/|\\\\}}as" "--32"
// CHECK-MULTI64-I386: "{{.*}}/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/bin{{/|\\\\}}ld"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI64-I386: "--sysroot=[[sysroot:.*/Inputs/basic_linux_tree]]"
// CHECK-MULTI64-I386: "-m" "elf_i386"
With help from chapuni on IRC, I think this is right now. =] The issue is that the command is quoted differently from the arguments. The command has '\' and the argument has '\\'. This is made unclear because FileCheck escapes the single matched '\' when it prints the contents of the variable, thus fooling me into thinking it had matched '\\' as intended. The solution is to bind the gcc_install variable in the argument list rather than out of the command. To do so we also have to be a bit more careful so that we don't get stray other things into the '.*' regex. Also, because of the argument difference, '\\\\' is the correct formulation before crtbegin, go back to that. llvm-svn: 187489
2013-07-31 19:14:13 +08:00
// CHECK-MULTI64-I386: "crti.o" "[[gcc_install:.*/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0]]/32{{/|\\\\}}crtbegin.o"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI64-I386: "-L[[gcc_install]]/32"
// CHECK-MULTI64-I386: "-L[[gcc_install]]/../../../../x86_64-unknown-linux/lib/../lib32"
// CHECK-MULTI64-I386: "-L[[gcc_install]]"
// CHECK-MULTI64-I386: "-L[[gcc_install]]/../../../../x86_64-unknown-linux/lib"
// CHECK-MULTI64-I386: "-L[[sysroot]]/lib"
// CHECK-MULTI64-I386: "-L[[sysroot]]/usr/lib"
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
//
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -o %t %s 2>&1 -no-integrated-as -fuse-ld=ld \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: --gcc-toolchain=%S/Inputs/multilib_64bit_linux_tree/usr \
// RUN: --target=x86_64-unknown-linux \
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
Update a comment to clarify that searching the target triple bin directory for programs used by the driver is actually the standard behavior we want to be compatible with GCC cross compilers -- it isn't specific to SUSE or any other distro. Also start fleshing out testing of the different cross compilation patterns, both with a new very bare-bones tree of cross compilers and by extending the multilib trees. Currently, we don't correctly model doing a cross compile using the non-triple target of a bi-arch GCC install, but I'll add support for that (and tests) next. llvm-svn: 184499
2013-06-21 07:37:54 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MULTI64-X86-64 %s
// CHECK-MULTI64-X86-64: "-cc1" "-triple" "x86_64-unknown-linux"
Fix Driver tests that I broke on Windows in r214924 llvm-svn: 214931
2014-08-06 06:39:07 +08:00
// CHECK-MULTI64-X86-64: "{{.*}}/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/bin{{/|\\\\}}as" "--64"
// CHECK-MULTI64-X86-64: "{{.*}}/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/bin{{/|\\\\}}ld"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI64-X86-64: "--sysroot=[[sysroot:.*/Inputs/basic_linux_tree]]"
// CHECK-MULTI64-X86-64: "-m" "elf_x86_64"
With help from chapuni on IRC, I think this is right now. =] The issue is that the command is quoted differently from the arguments. The command has '\' and the argument has '\\'. This is made unclear because FileCheck escapes the single matched '\' when it prints the contents of the variable, thus fooling me into thinking it had matched '\\' as intended. The solution is to bind the gcc_install variable in the argument list rather than out of the command. To do so we also have to be a bit more careful so that we don't get stray other things into the '.*' regex. Also, because of the argument difference, '\\\\' is the correct formulation before crtbegin, go back to that. llvm-svn: 187489
2013-07-31 19:14:13 +08:00
// CHECK-MULTI64-X86-64: "crti.o" "[[gcc_install:.*/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0]]{{/|\\\\}}crtbegin.o"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI64-X86-64: "-L[[gcc_install]]"
Revert "Support cross linking to arm on ubuntu." This reverts commit r193528 (and fixes). It broke Chandler's setup. llvm-svn: 193554
2013-10-29 07:14:34 +08:00
// CHECK-MULTI64-X86-64: "-L[[gcc_install]]/../../../../x86_64-unknown-linux/lib/../lib64"
Find a better compromise with the default library search paths used by Clang when linking and using a GCC installation from a GCC cross-compiler. This was desired already by two special case platforms (Android and Mips), and turns out to be generally (if frustratingly) true. I've added a substantial comment to the code clarifying the underlying assumptions of doing actual cross compiles with Clang (or GCC for that matter!) and help avoid further confusion here. The end result is to realize that fully general form of PR12478 cannot be resolved while we support existing cross-compiling GCC toolchains, and linking with them (namely, linking against their libgcc and libstdc++ installs). GCC installs these target libraries under a target-specific prefix but one that may not be available within the actual sysroot in use. When linking in this world, GCC works and Clang should as well, but caveat emptor: DSOs from this tree must be replicated and rpath-fixed to be found at runtime within the sysroot. I've extended the cross compile test cases to cover these issues by pointing them at a sysroot and actually checking the library search paths. llvm-svn: 187466
2013-07-31 08:37:07 +08:00
// CHECK-MULTI64-X86-64: "-L[[gcc_install]]/../../../../x86_64-unknown-linux/lib"
// CHECK-MULTI64-X86-64: "-L[[sysroot]]/lib"
// CHECK-MULTI64-X86-64: "-L[[sysroot]]/usr/lib"