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/lib-search-paths.yaml

17 lines
581 B
YAML
Raw Normal View History

Replace -flavor {gnu,darwin} with ld64.lld or ld.lld. llvm-svn: 325390
2018-02-17 05:16:57 +08:00
# RUN: ld64.lld -arch x86_64 %s -syslibroot %p/Inputs/lib-search-paths -lmyshared -lmystatic -lfile.o -r -print_atoms 2>&1 | FileCheck %s
[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
--- !native
undefined-atoms:
- name: _from_myshared
- name: _from_mystatic
- name: _from_fileo
# CHECK: defined-atoms:
# CHECK: - name: _from_fileo
# CHECK: content: [ 2A, 00, 00, 00 ]
Subclass InputGraph to get darwin linker library semantics The darwin linker operates differently than the gnu linker with respect to libraries. The darwin linker first links in all object files from the command line, then to resolve any remaining undefines, it repeatedly iterates over libraries on the command line until either all undefines are resolved or no undefines were resolved in the last pass. When Shankar made the InputGraph model, the plan for darwin was for the darwin driver to place all libraries in a group at the end of the InputGraph. Thus making the darwin model a subset of the gnu model. But it turns out that does not work because the driver cannot tell if a file is an object or library until it has been loaded, which happens later. This solution is to subclass InputGraph for darwin and just iterate the graph the way darwin linker needs. llvm-svn: 220330
2014-10-22 05:14:11 +08:00
# CHECK: - name: _from_mystatic
# CHECK: content: [ 02, 00, 00, 00 ]
[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: shared-library-atoms:
# CHECK: - name: _from_myshared
# CHECK: load-name: libmyshared.dylib