https://sourceware.org/bugzilla/show_bug.cgi?id=23729
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
I believe the changed behaviour is simply a bug fix. Consider how
--start-group libfunc.a main.o -T export.ld --end-group
should work. On the first iteration over object files:
- libfunc.a is searched for symbols that define currently undefined symbols,
none are found so no object files are extracted,
- main.o symbols are loaded, giving an undefined "func",
- export.ld is processed, which provides "func".
Since --start-group/--end-group wrap these three files, the library is searched
again for symbols that define currently undefined symbols, but "func" is now
defined (by the PROVIDE) so the object is not extracted..
Similar analysis applied to
-T export.ld --start-group libfunc.a main.o --end-group
or
--start-group libfunc.a main.o --end-group -T export.ld
says the linker is working properly there too.
The older binutils did not process the export.ld "PROVIDE" statement early
enough to define "func". You could probably see this difference between
binutils-2.26 and current binutils without --start-group/--end-group with
main.o -T export.ld libfunc.a
Thus a documentation change for --start-group/--end-group is not appropriate.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
