https://sourceware.org/bugzilla/show_bug.cgi?id=15478
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #15 fr
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #14 from Dave Cunningham 2013-05-21
15:31:17 UTC ---
OK, so here are the options, in decreasing order of my personal preference :)
1) Do the graph traversal to make --as-needed compatible with GNU ld
2) Rename --as-needed to --as-
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #13 from Ian Lance Taylor 2013-05-21 04:18:43
UTC ---
As far as I can see plain GCC only uses --as-needed in the form
--as-needed -lgcc_s --no-as-needed
If your GCC is always passing --as-needed to ld I think that must be Debi
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #12 from Dave Cunningham 2013-05-21
00:27:30 UTC ---
I guess you need to do a full mark/sweep. It's similar to garbage collection,
except instead of heap objects you have .so files, the .o files are the stack,
and the symbols are
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #11 from Cary Coutant 2013-05-20
21:43:58 UTC ---
> diff --git a/gold/symtab.cc b/gold/symtab.cc
> index 2e17529..595df56 100644
> --- a/gold/symtab.cc
> +++ b/gold/symtab.cc
> @@ -2381,7 +2381,17 @@ Symbol_table::set_dynsym_indexe
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #10 from Cary Coutant 2013-05-20
17:41:58 UTC ---
> That is rather explicit, isn't it? For gold to match this behavior, I
> think all we need to do is remove the test for sym->in_reg() in the
> following code in Symbol_table::set_d
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #9 from Cary Coutant 2013-05-20
16:46:00 UTC ---
> Here is the documentation from older binutils which talks about --as-needed
> interpreting undefined symbols both .o and .so files:
>
>--as-needed
>--no-as-needed
>
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #8 from Dave Cunningham 2013-05-19
23:26:42 UTC ---
There doesn't seem to be any relationship between --allow-shlib-undefined and
--as-needed.
There is no undefined symbol in the link job, everything is satisfied by the
libraries
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #7 from Ian Lance Taylor 2013-05-18 18:10:26
UTC ---
Rather than make this rather complex behaviour even more complex in order to
satisfy your rather unusual use case, I suggest that you use the
--allow-shlib-undefined option.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #6 from Dave Cunningham 2013-05-17
19:45:56 UTC ---
> In this specific case, yes, no searching is necessary, but in the
> general case, if we're going to try to resolve undefined symbols in
> shared libraries, we need to process th
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #5 from Cary Coutant 2013-05-17
18:48:34 UTC ---
>> I think this is a behavior of the Gnu linker that gold is better off
>> not copying. The linker ends up having to replicate the path searching
>> done at runtime by the dynamic lo
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #4 from Dave Cunningham 2013-05-17
15:58:14 UTC ---
> I think this is a behavior of the Gnu linker that gold is better off
> not copying. The linker ends up having to replicate the path searching
> done at runtime by the dynamic lo
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #3 from Cary Coutant 2013-05-17
04:50:56 UTC ---
> Yes that mode of operation does work but is unfortunately not an option for us
> as we would like to combine libmylib.so with a different API-compatible
> libmyplugin.so in each of
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #2 from Dave Cunningham 2013-05-17
01:46:41 UTC ---
> I think this is intended behavior for gold. It's expected that each
> library will have its own dependencies recorded so that we only record
> direct dependencies in the dynamic
http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #1 from Cary Coutant 2013-05-16
23:51:51 UTC ---
> situation (see attached tar.bz2 to reproduce):
> libmylib.so has unresolved symbols that are found in libmyplugin.so
> myapp.c++ calls into libmylib.so
> myapp.c++ is being compile
15 matches
Mail list logo
