-V prints the version information in both BSD and GNU ar/ranlib.
BSD ranlib rejects -v while -v enables verbose output in GNU ar but is
another alias for --version in GNU ranlib. The GNU ranlib behavior is
inconsistent: `ranlib -v` is different from `ar -sv`. But it's not a
major concern in practice:
* Users typically use ranlib solely for creating archive symbol tables,
and they don't need verbose output.
* Verbose output in ranlib seems a no-op.
* GNU ar creates an archive symbol table by default. Many ranlib uses
have been eliminated.
* Modern linkers like lld/ELF (since version 14) and mold don't rely on
archive symbol tables anymore.
https://reviews.llvm.org/D71554 introduced -v. This patch removes it so
that `llvm-ranlib -v` and `llvm-ranlib -version` lead to errors (GNU
ranlib rejects `-version` as well). -V is added as an alias for
--version.
Close#87654
Pull Request: https://github.com/llvm/llvm-project/pull/87661
There are a few test that check access permissions, so they need to be
disabled when running the tests as root.
The most common use case for running tests as root is inside of a
container. GitHub Actions, for example, only supports running the root
user inside of containers, so this change is necessary in order to run
the tests inside of a container running in the GitHub Actions
environment.
Summary:
llvm-ar is symlinked as llvm-ranlib and will act as ranlib when invoked in that mode. llvm-ar since [[ 4f2cfbe531 | compiler/llvm-project@4f2cfbe ]] supports the -X options, but doesn't seem to accept them when running as llvm-ranlib.
In AIX OS , according to https://www.ibm.com/docs/en/aix/7.2?topic=r-ranlib-command
-X mode Specifies the type of object file ranlib should examine. The mode must be one of the following:
32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64, any
Processes both 32-bit and 64-bit object files
The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes ranlib to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
Reviewers: James Henderson, MaskRay, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D142660
BSD and GNU ranlib support more than one input file. Implement this.
While here, update OVERVIEW (Ranlib => ranlib) since "ranlib" is more common.
Remove "speed access" since the index has nothing to do with performance: it is
mandatory for GNU ld and gold but ignored for ld.lld (D119074).
Close https://github.com/llvm/llvm-project/issues/54565
Differential Revision: https://reviews.llvm.org/D131375
Modify llvm-ar and llvm-ranlib to use the actual name of the executable
when printing the usage text via the '--help' flag.
Reviewers: Maskray, jhenderson, gbreynoo
Differential Revision: https://reviews.llvm.org/D124445
On Windows hosts, the error message will be something like
`c:\src\llvm-project\out\gn\bin\llvm-ranlib.exe: error: Invalid option: '--D'`.
Due to the .exe after llvm-ranlib the existing CHECK lines do not match.
Fix this by ignoring the program name and starting the check line at "error:".
It appears that Windows hosts always report rwxrwxrwx even with the
chmod 644 invocation. As this test only cares about the timestamps
and not the permissions, use a regex wildcard instead.
The version string can be customized by CMake options, so the 'LLVM
version' substring is not guaranteed to appear (see
VersionPrinter::print in llvm/lib/Support/CommandLine.cpp).
Not all systems create the .o file with mode 644 by default.
Adding an explicit chmod invocation should fix this test added in
535b3c6b2f1c81ed91942ebd9ea06a1022dc59a1
I have been trying to build CheriBSD (a fork for FreeBSD for the CHERI
CPU) with LLVM binutils instead of the default elftoolchain utilities.
I noticed that building static archives was failing because ranlib is
invoked with the -D flag. This failed with llvm-ranlib since it parses
the -D flag as the archive path and reports an error that more than one
archive has been passed.
This fixes https://llvm.org/PR41707
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D71554
If llvm-ar is installed at arm-pokymllib32-linux-gnueabi-llvm-ar, it may
think it is llvm-lib due to the "lib" substring.
Improve the heuristic to make all the following work as intended:
llvm-ar-9 (llvm-9 package on Debian)
llvm-ranlib.exe
Lib.exe (reported by D44808)
arm-pokymllib32-linux-gnueabi-llvm-ar (reported by D71030)
Reviewed By: raj.khem, rupprecht
Differential Revision: https://reviews.llvm.org/D71302
Also, fix a bug in ranlib where it didn't correctly detect being run
without any argument and would try to operate on the empty string.
Differential Revision: https://reviews.llvm.org/D70021
