Summary: | ar: with -T option disabled | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Ed Maste <emaste> | ||||
Component: | bin | Assignee: | Ed Maste <emaste> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Some People | CC: | bhughes, emaste, hrs, portmgr, toolchain | ||||
Priority: | --- | Flags: | koobs:
maintainer-feedback?
(emaste) koobs: mfc-stable13+ koobs: mfc-stable12+ koobs: exp-run+ |
||||
Version: | CURRENT | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
URL: | https://reviews.freebsd.org/D33553 | ||||||
See Also: |
https://github.com/llvm/llvm-project/issues/25899 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260810 |
||||||
Bug Depends on: | 260596 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Ed Maste
2021-12-18 18:46:21 UTC
New failure logs: http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/gn-1897.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/ja-mozc-server-2.23.2815.102.01_5.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/ja-mozc-tool-2.23.2815.102.01_5.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/node-17.0.1.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/node10-10.24.1_2.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/node14-14.18.1_1.log http://gohan04.nyi.freebsd.org/data/main-amd64-PR260523-default/2021-12-21_16h10m27s/logs/errors/node16-16.13.0.log node expects T to mean thin, not truncate archive member names -- the ar flags (crsT) are defined in a cmd_alink_thin variable. devel/gn is the same, rcsT is defined in "rule alink_thin" I didn't find the ar invocation in japanese/mozc-server but it appears to be the same case. CCing affected maintainers. The ports you maintain invoke /usr/bin/ar with the -T flag expecting it to mean create a thin .a archive, but our ar truncates member names to 15 characters with -T. In the short term these ports should either drop T from flags passed to ar, or use llvm-ar or GNU ar as a build dependency. We will transition to using llvm-ar as /usr/bin/ar in the medium term, and these could switch back to /usr/bin/ar with -T at that point. For devel/gn: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260596 A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=edadbb46065d9ee9559140b2522197fcdba57064 commit edadbb46065d9ee9559140b2522197fcdba57064 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2021-12-29 19:59:06 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2021-12-29 20:14:06 +0000 ar: deprecate -T option Other ar implementations (GNU, LLVM) use -T to mean thin archive rather than use only the first fifteen characters of the archive member name. We support both -T and -f for this, with -f documented as an alias of -T. An exp-run showed that the ports invoking `ar -T` expect thin archives, not truncated names. Switch -f to be the documented flag for this behaviour, and emit a warning when -T is used. The warning will be changed to an error in the future (in main), once ports no longer use -T. PR: 260523 [exp-run] MFC after: 1 week Sponsored by: The FreeBSD Foundation usr.bin/ar/ar.1 | 14 +++++++++----- usr.bin/ar/ar.c | 6 +++++- 2 files changed, 14 insertions(+), 6 deletions(-) I have changed my mind and think we should start accepting (but ignoring) -T, rather than failing: * `-f` / old `-T` functionality is not particularly useful * ports invoking `ar -T` expect thin archives * non-thin archives are compatible and functional, just larger * a future migration to LLVM-ar will introduce `-T` thin archive support I have updated https://reviews.freebsd.org/D33553 to reflect this. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1a0a41b10566e75e77e7efbc8475622b6a37ffbf commit 1a0a41b10566e75e77e7efbc8475622b6a37ffbf Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2022-01-03 16:32:52 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2022-01-03 16:42:59 +0000 ar: accept but ignore 'T' option In previous versions of BSD ar -T was an alias for -f -- use only the first 15 characters of archive member names. In GNU ar and LLVM ar -T creates a thin archive. The -f / old BSD ar -T functionality is not particularly useful, and ignoring -T still results in a usable and compatible (but not thin) archive. An exp-run found a few ports invoking ar -T but they all expect thin archives. In addition, -T will be used to specify thin archives after a migration to LLVM-ar. PR: 260523 [exp-run] Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D33553 usr.bin/ar/ar.1 | 5 ++--- usr.bin/ar/ar.c | 3 +-- 2 files changed, 3 insertions(+), 5 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2076973231d8d2e1c46bc5825e676a44643b6bfa commit 2076973231d8d2e1c46bc5825e676a44643b6bfa Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2021-12-29 19:59:06 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2022-01-05 01:53:27 +0000 ar: deprecate -T option Other ar implementations (GNU, LLVM) use -T to mean thin archive rather than use only the first fifteen characters of the archive member name. We support both -T and -f for this, with -f documented as an alias of -T. An exp-run showed that the ports invoking `ar -T` expect thin archives, not truncated names. Switch -f to be the documented flag for this behaviour, and emit a warning when -T is used. The warning will be changed to an error in the future (in main), once ports no longer use -T. PR: 260523 [exp-run] MFC after: 1 week Sponsored by: The FreeBSD Foundation (cherry picked from commit edadbb46065d9ee9559140b2522197fcdba57064) usr.bin/ar/ar.1 | 14 +++++++++----- usr.bin/ar/ar.c | 6 +++++- 2 files changed, 14 insertions(+), 6 deletions(-) A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=df898828a4dc585d5be65ac710dbe0fdf9d7b3b9 commit df898828a4dc585d5be65ac710dbe0fdf9d7b3b9 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2021-12-29 19:59:06 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2022-01-05 01:54:04 +0000 ar: deprecate -T option Other ar implementations (GNU, LLVM) use -T to mean thin archive rather than use only the first fifteen characters of the archive member name. We support both -T and -f for this, with -f documented as an alias of -T. An exp-run showed that the ports invoking `ar -T` expect thin archives, not truncated names. Switch -f to be the documented flag for this behaviour, and emit a warning when -T is used. The warning will be changed to an error in the future (in main), once ports no longer use -T. PR: 260523 [exp-run] MFC after: 1 week Sponsored by: The FreeBSD Foundation (cherry picked from commit edadbb46065d9ee9559140b2522197fcdba57064) usr.bin/ar/ar.1 | 14 +++++++++----- usr.bin/ar/ar.c | 6 +++++- 2 files changed, 14 insertions(+), 6 deletions(-) ^Triage: No longer an exp-run (please just just the flag). Assign to committer resolving, re-classify (base issue, affecting ports, with base change) Given comment 10: "The warning will be changed to an error in the future (in main), once ports no longer use -T." .. leave issues blocking this (in progress) issue, at least for tracking purposes. @Ed Is there any value/desire here to change our ar over time / long-term to be consistent with other ar's, or is that effective a noop given the switch to llvm-ar? Said another way, is the target state that 'our ar' is deprecated and removed? ^Triage: Track merges > @Ed Is there any value/desire here to change our ar over time / long-term to be consistent with other ar's, or is that effective a noop given the switch to llvm-ar? Said another way, is the target state that 'our ar' is deprecated and removed?
Yes, my expectation is that we will switch to llvm-ar and that will introduce -T thin archive support consistent with GNU ar and others.
Note that I currently do not expect to MFC 1a0a41b10566e75e77e7efbc8475622b6a37ffbf, to avoid functional changes in stable branches. It'd be best for ports to stop invoking `ar -T` (when they wish to produce a thin archive), but it's reduced in importance: on stable branches they will use truncated member names (as they have for years) and on main -T will be silently ignored. |