On 15/04/2023 15:47, наб wrote:
On Sat, Apr 15, 2023 at 02:04:18PM +0100, Pádraig Brady wrote:
But perhaps the strip program doesn't handle the convention
that -- indicates end of option processing?
Inasmuch as "perhaps strip doesn't use getopt(3)" /and/
"perhaps strip doesn't conform to the XCU"
(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/strip.html;
note no changes since Issue 2, which means this has been a requirement
realistically since 1989
(it's in my copy of XSI Issue 3, saying it's equivalent to Issue 2,
but it's only Volume 1, and it's unclear to me if the XBD USG
was fully developed; Issue 2 hasn't been archived),
and definitely since SUSv1, whose Guideline 10 and Utility Description
Defaults, OPTIONS, Default Behaviour are both as present-day)
can both hold at the same time, I guess?
You can probably tell I'm quite sceptical any such strip exists.
I was thinking of the more general case where the strip program
may be a shell wrapper or something that doesn't handle -- appropriately.
The main point is that we should fix this issue in any case.
It would also be nice for $STRIP to provide a default if -S isn't set;
the usefulness of install -s is doubtful if
install -s binary $DESTDIR/bin
only works if binary happens to match the host arch.
Yes it's a fair point that calling strip without options is quite restrictive.
Though I suppose --strip-program can point to a script that calls strip
appropriately.
My target usecase is for third-party programs running install -s,
which, without modification, cannot be made to work if strip is binutils
strip and the binary is non-native.
Well one could adjust the $PATH so an appropriate strip wrapper is found.
cheers,
Pádraig
