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. > > That was the part of the original proposal I didn't agree with and I > still don't do. While the resolver shouldn't have to deal with the > details of the command line, it certainly should know about the input > graph. I wouldn't be surprised if it can make a significant difference > for group processing whether a DFS or BFS is applied, even if the result > doesn't change. There are other concerns like the recursive processing > of DT_NEEDED for ELF and the resulting implications for symbol > resolution and locking.Someone should certainly know about the input graph, but it isn't necessarily be Resolver. In my proposal Linking Context gets update for each step of linking from Resolver and makes a decision based on that. I don't see why you think the search order would change in this model. I think it shouldn't change. 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/1541c21a/attachment.html>
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
Hi Joerg,
I would 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 to `fn1'
Any ways of making the GNU linker do a DFS/BFS search on dependent
libraries ?
Thanks
Shankar Easwaran
On 9/21/2013 5:25 AM, Joerg Sonnenberger wrote:> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation