search for: libfn1

Displaying 4 results from an estimated 4 matches for "libfn1".

2013 Sep 21
1
[LLVMdev] LLD input graph handling proposal
...uld love to have this behavior(solaris/hp-ux linkers used to do this). cat > main.c << \! int main() { fn(); fn1(); } ! cat > fn.c << \! int fn() { return 0; } ! cat > fn1.c << \! int fn1() { return 0; } ! gcc -c -fPIC main.c fn.c fn1.c ld -shared fn1.o -o libfn1.so ld -shared fn.o -o libfn.so -L. -lfn1 ld main.o libfn.so ld: warning: libfn1.so, needed by libfn.so, not found (try using -rpath or -rpath-link) ld: warning: cannot find entry symbol _start; defaulting to 00000000004002f0 main.o: In function `main': main.c:(.text+0x14): undefined reference...
2013 Sep 21
0
[LLVMdev] LLD input graph handling proposal
On Fri, Sep 20, 2013 at 05:29:32PM -0700, Rui Ueyama wrote: > I don't also understand if DT_NEEDED is related to this. DT_NEEDED is not > represented by input graph. And what is *recursive* processing of DT_NEEDED? Searching a symbol in a shared library according to ELF semantics means recursively searching in all depending libraries as well. Joerg
2013 Sep 21
2
[LLVMdev] LLD input graph handling proposal
On Fri, Sep 20, 2013 at 5:08 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Fri, Sep 20, 2013 at 04:39:04PM -0700, Rui Ueyama wrote: > > I don't want to make Resolver to have a reference to input graph. The > point > > of this proposal is to separate input graph handling from Resolver and > > instead making Linker Context to do that task. >
2014 Jul 01
7
[LLVMdev] [lld] [mach-o]: RFC: representing LC_REEXPORT_DYLIB
Hi all, I've been thinking about how best to represent MachO's LC_REEXPORT_DYLIB (used even by libSystem.dylib to provide its various sub-components[*]). It looks like this functionality would naturally fall into the InputGraph, in analogy with Groups and Archives. Unfortunately, it's rather more dynamic than the existing cases: we don't know the needed files before parsing the