https://sourceware.org/bugzilla/show_bug.cgi?id=32550
Bug ID: 32550
Summary: ranlib manipulation of MSVC ".lib" files can lead to
awkward corruption
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: mitch.capper at gmail dot com
Target Milestone: ---
Created attachment 15878
--> https://sourceware.org/bugzilla/attachment.cgi?id=15878&action=edit
MSVC generated library before ranlib
I don't know if ranlib is designed to be MSVC lib.exe's ".lib" library file
compatible or not but it seems it is mostly compatible and that can lead to
some annoying bugs. I do see references to windows/MSVC in the ar source so I
would lean towards yes. Of course ranlib shouldn't be used on MSVC .libs,
they already have indexes. For most people they probably shouldn't even have
ranlib in their path on Windows. Sadly combos like GitHub trying to include
every dev tool in their CI images combined with libtool happily using ranlib no
matter the OS or if it is needed if it is present in the path (
https://savannah.gnu.org/support/?111171 ) when you get this perfect storm you
have some fun. The libraries, after ranlib, are still mostly useable. The
problem is the index is partly corrupted, due to 'improper' handling of
backslashes (which windows uses for the path ;0). What is a bit worse is `ar
-t` lists the files fine after the corruption. lib.exe -LIST shows the slashes
all the same (windows standard) direction in the before.lib even though clearly
they are not.
I have attached a sample library (before.lib) and the result of running ranlib
on it (after.lib).
`ar t before.lib`
```
gost/cmac-kuznyechik.obj
gost/cmac-magma.obj
gost\acpkm.obj
gost/kuznyechik.obj
gost\magma.obj
gost_keywrap.obj
gost/gostdsa-mask.obj
gost/bignum-le.obj
gost/hmac-streebog.obj
gost/streebog-meta.obj
gost/streebog.obj
gost/gost-wrap.obj
gost/gost28147.obj
gost/write-le32.obj
rnd-fuzzer.obj
sysrng-bcrypt.obj
int\rsa-pad.obj
int/mpn-base256.obj
int/ecdsa-compute-k.obj
int/dsa-compute-k.obj
int/tls1-prf.obj
int/dsa-validate.obj
int/dsa-keygen-fips186.obj
int/provable-prime.obj
int/rsa-keygen-fips186.obj
rnd.obj
prf.obj
init.obj
cipher.obj
mac.obj
mpi.obj
pk.obj
```
`ar t after.lib`
```
cmac-kuznyechik.obj
cmac-magma.obj
acpkm.obj
kuznyechik.obj
magma.obj
gost_keywrap.obj
gostdsa-mask.obj
bignum-le.obj
hmac-streebog.obj
streebog-meta.obj
streebog.obj
gost-wrap.obj
gost28147.obj
write-le32.obj
rnd-fuzzer.obj
sysrng-bcrypt.obj
rsa-pad.obj
mpn-base256.obj
ecdsa-compute-k.obj
dsa-compute-k.obj
tls1-prf.obj
dsa-validate.obj
dsa-keygen-fips186.obj
provable-prime.obj
rsa-keygen-fips186.obj
rnd.obj
prf.obj
init.obj
cipher.obj
mac.obj
mpi.obj
pk.obj
```
`lib -LIST -NOLOGO .\before.lib`
```
pk.obj
mpi.obj
mac.obj
cipher.obj
init.obj
prf.obj
rnd.obj
int\rsa-keygen-fips186.obj
int\provable-prime.obj
int\dsa-keygen-fips186.obj
int\dsa-validate.obj
int\tls1-prf.obj
int\dsa-compute-k.obj
int\ecdsa-compute-k.obj
int\mpn-base256.obj
int\rsa-pad.obj
sysrng-bcrypt.obj
rnd-fuzzer.obj
gost\write-le32.obj
gost\gost28147.obj
gost\gost-wrap.obj
gost\streebog.obj
gost\streebog-meta.obj
gost\hmac-streebog.obj
gost\bignum-le.obj
gost\gostdsa-mask.obj
gost_keywrap.obj
gost\magma.obj
gost\kuznyechik.obj
gost\acpkm.obj
gost\cmac-magma.obj
gost\cmac-kuznyechik.obj
```
`lib -LIST -NOLOGO .\after.lib`
```
pk.obj
mpi.obj
mac.obj
cipher.obj
init.obj
prf.obj
rnd.obj
rsa-keygen-fips186.obj
provable-prime.obj
dsa-keygen-fips186.obj
dsa-validate.obj
tls1-prf.obj
dsa-compute-k.obj
ecdsa-compute-k.obj
mpn-base256.obj
rsa-pad.obj/obj
sysrng-bcrypt.obj
rnd-fuzzer.obj
write-le32.obj
gost28147.obj
gost-wrap.obj
streebog.obj
streebog-meta.obj
hmac-streebog.obj
bignum-le.obj
gostdsa-mask.obj
gost_keywrap.obj
magma.obj/.obj
kuznyechik.obj
acpkm.obj/.obj
cmac-magma.obj
cmac-kuznyechik.obj
```
The "gost\magma.obj" => "magma.obj/.obj"
So lots of blame for why this shouldn't happen to go around but a great fix
would be in ranlib detected a MSVC library to just no-op or to exit 1 warning
the user it shouldn't be used on a VC ".lib". Alternatively it could be
changed to handle the backslash.
--
You are receiving this mail because:
You are on the CC list for the bug.
