https://sourceware.org/bugzilla/show_bug.cgi?id=24281
Nick Clifton <nickc at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-03-01
CC| |nickc at redhat dot com
Ever confirmed|0 |1
--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
Hi lol lol,
Hmm, you do realise that copying a thin library in this way is
essentially the same thing as just copying it normally, right ?
The question is, what would you expect objcopy to do if you also
had one or more of its transformation options enabled as well.
For example, what should this do:
objcopy --strip-debug out.a out_copy.a
Would you expect objcopy to create new versions of all of the
object files linked to within out.a, with the debugging stripped
from the new versions ? If so, what names should be given to
these new object files ? Or how about:
objcopy out.a subdir/copy.a
Would you expect objcopy to leave the object files intact but to
rename the links inside copy.a so that they are valid for the
new location of the thin library ?
It seems to me that the easiest thing to do would be to just
reject attempts to objcopy thin archives. But maybe this is
too draconian. Would you be happy if an in-place copy of a
thin archive was allowed, but transformations, or relocations
were refused ?
Cheers
Nick
--
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
