bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/24281] Failed with “thin archive” if it contain subdir's o


From: qwertytmp1 at gmail dot com
Subject: [Bug binutils/24281] Failed with “thin archive” if it contain subdir's object file
Date: Mon, 04 Mar 2019 08:55:24 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=24281

--- Comment #3 from lol lol <qwertytmp1 at gmail dot com> ---
Hi Nick,


Q. Hmm, you do realise that copying a thin library in this way is 
   essentially the same thing as just copying it normally, right?
A. Yes. It was chosen for simplicity. Anyway, it shouldn't fail. Can you agree?


Q. 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
A. I expect similar behavior as for other "non-thin" object files.
   Why not to do "--strip-debug" for all included files recursively?
   It may be done in-place, or done with a copy.


Q. 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 ?
A. In this case (case, when objcopy pretends to change object files), we may
   simply notify user, that object files will be rewritten and wait for the 
   confirmation.


Q. 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?
A. I think, it is not a bad idea to simply disallow objcopy for thin archives
   till the moment, when it will be supported (in alternative future).
   I think it is not of "draconian" attempt.
   This way, user of this magic tool will not be confused at all.


Thank you!

WBR,
lol lol

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]