With a newer .lib archive (MSVC 2019), arpy is unable to parse this, giving this error:
Python 3.9.6 (tags/v3.9.6:db3ff76, Jun 28 2021, 15:26:21) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import arpy
>>> import pefile
>>> a = arpy.Archive(r"libssl_static.lib")
>>> a.namelist()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "...\lib\site-packages\arpy.py", line 412, in namelist
self.read_all_headers()
File "...\lib\site-packages\arpy.py", line 397, in read_all_headers
while self.read_next_header() is not None:
File "...\lib\site-packages\arpy.py", line 372, in read_next_header
header = self.__read_file_header(self.next_header_offset)
File "...\lib\site-packages\arpy.py", line 299, in __read_file_header
add_len = self.__fix_name(file_header)
File "...\lib\site-packages\arpy.py", line 346, in __fix_name
raise ArchiveFormatError("file references a name not present in the index")
arpy.ArchiveFormatError: file references a name not present in the index
I attached the .lib that's causing this issue:
libssl_static.zip
I attempted to address this with a PR (#17) that detects if NULL characters exist in HEADER_GNU_TABLE, and if so, uses that to split and figure out the file names instead of newline. Did some testing as well by dumping the object files out with arpy + binutils ar, and comparing the two - both for files that are oddly marked (e.g. specify /(number) as their filename) and for files that are properly named.
Oddly marked file example (shown with PEView, a very awesome tool used for debugging this issue):

Note that the hex does not match the resolved name it comes up with as it's using the HEADER_GNU_TABLE to resolve it.
If you would like to poke at it yourself with 010 Editor, here's a template that you can run on the .lib file. Output of that template:

With a newer .lib archive (MSVC 2019), arpy is unable to parse this, giving this error:
I attached the .lib that's causing this issue:
libssl_static.zip
I attempted to address this with a PR (#17) that detects if NULL characters exist in HEADER_GNU_TABLE, and if so, uses that to split and figure out the file names instead of newline. Did some testing as well by dumping the object files out with arpy + binutils ar, and comparing the two - both for files that are oddly marked (e.g. specify /(number) as their filename) and for files that are properly named.
Oddly marked file example (shown with PEView, a very awesome tool used for debugging this issue):

Note that the hex does not match the resolved name it comes up with as it's using the HEADER_GNU_TABLE to resolve it.
If you would like to poke at it yourself with 010 Editor, here's a template that you can run on the .lib file. Output of that template:
