maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/mach-o/libresolve-simple.yaml

22 lines
747 B
YAML
Raw Normal View History

[mach-o] Support -filelist option in darwin driver The darwin linker has an option, heavily used by Xcode, in which, instead of listing all input files on the command line, the input file paths are written to a text file and the path of that text file is passed to the linker with the -filelist option (similar to @file). In order to make test cases for this, I generalized the -test_libresolution option to become -test_file_usage. llvm-svn: 215762
2014-08-16 03:53:41 +08:00
# RUN: lld -flavor darwin -arch x86_64 -r -test_file_usage -v \
[mach-o]: support -syslibroot and -l options These behave slightly idiosyncratically in the best of cases, and have additional hacks layered on top of that for compatibility with badly behaved build systems (via ld64). For -lXYZ: + If XYZ is actually XY.o then search all library paths for XY.o + Otherwise search all library paths, first for libXYZ.dylib, then libXYZ.a + By default the library paths are /usr/lib and /usr/local/lib in that order. For -syslibroot: + -syslibroot options apply to absolute paths in the search order. + All -syslibroot prefixes that exist are added to the search path *instead* of the original. + If no -syslibroot prefixed path exists, the original is kept. + Hacks^WExceptions: + If only 1 -syslibroot is given and doesn't contain /usr/lib or /usr/local/lib, that path is dropped entirely. (rdar://problem/6438270). + If the last -syslibroot is "/", all of them are ignored entirely. (rdar://problem/5829579). At least, that's my best interpretation of what ld64 does in buildSearchPaths. llvm-svn: 212706
2014-07-10 19:21:06 +08:00
# RUN: -path_exists /usr/lib \
# RUN: -path_exists /usr/local/lib \
# RUN: -path_exists /usr/lib/libSystem.dylib \
[mach-o]: support user-specified (-L) library search paths llvm-svn: 212712
2014-07-10 19:46:08 +08:00
# RUN: -path_exists hasFoo \
# RUN: -path_exists hasFoo/libFoo.dylib \
# RUN: -path_exists /hasBar \
# RUN: -path_exists /hasBar/libBar.dylib \
# RUN: -L hasFoo \
# RUN: -L /hasBar \
# RUN: -lSystem -lFoo -lBar \
[mach-o]: support -syslibroot and -l options These behave slightly idiosyncratically in the best of cases, and have additional hacks layered on top of that for compatibility with badly behaved build systems (via ld64). For -lXYZ: + If XYZ is actually XY.o then search all library paths for XY.o + Otherwise search all library paths, first for libXYZ.dylib, then libXYZ.a + By default the library paths are /usr/lib and /usr/local/lib in that order. For -syslibroot: + -syslibroot options apply to absolute paths in the search order. + All -syslibroot prefixes that exist are added to the search path *instead* of the original. + If no -syslibroot prefixed path exists, the original is kept. + Hacks^WExceptions: + If only 1 -syslibroot is given and doesn't contain /usr/lib or /usr/local/lib, that path is dropped entirely. (rdar://problem/6438270). + If the last -syslibroot is "/", all of them are ignored entirely. (rdar://problem/5829579). At least, that's my best interpretation of what ld64 does in buildSearchPaths. llvm-svn: 212706
2014-07-10 19:21:06 +08:00
# RUN: 2>&1 | FileCheck %s
# CHECK: Library search paths:
[mach-o]: support user-specified (-L) library search paths llvm-svn: 212712
2014-07-10 19:46:08 +08:00
# CHECK: hasFoo
# CHECK: /hasBar
[mach-o]: support -syslibroot and -l options These behave slightly idiosyncratically in the best of cases, and have additional hacks layered on top of that for compatibility with badly behaved build systems (via ld64). For -lXYZ: + If XYZ is actually XY.o then search all library paths for XY.o + Otherwise search all library paths, first for libXYZ.dylib, then libXYZ.a + By default the library paths are /usr/lib and /usr/local/lib in that order. For -syslibroot: + -syslibroot options apply to absolute paths in the search order. + All -syslibroot prefixes that exist are added to the search path *instead* of the original. + If no -syslibroot prefixed path exists, the original is kept. + Hacks^WExceptions: + If only 1 -syslibroot is given and doesn't contain /usr/lib or /usr/local/lib, that path is dropped entirely. (rdar://problem/6438270). + If the last -syslibroot is "/", all of them are ignored entirely. (rdar://problem/5829579). At least, that's my best interpretation of what ld64 does in buildSearchPaths. llvm-svn: 212706
2014-07-10 19:21:06 +08:00
# CHECK: /usr/lib
# CHECK: /usr/local/lib
# CHECK: Found library /usr/lib/libSystem.dylib
[mach-o]: support user-specified (-L) library search paths llvm-svn: 212712
2014-07-10 19:46:08 +08:00
# CHECK: Found library hasFoo/libFoo.dylib
# CHECK: Found library /hasBar/libBar.dylib