Displaying 4 results from an estimated 4 matches for "libfn".
Did you mean:
libfc
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