mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-29 02:06:06 +00:00
c912e98e8e
This matches what MS lib.exe does (and llvm-ar too); when adding files to an archive, MS lib.exe stores the file name as it was given on the command line, whereas llvm-lib rewrote it into a relative path name, relative to the archive location. Such a rewrite makes sense for thin archives, but not for regular archives. (MS lib.exe doesn't support producing thin archives; that's an LLVM extension - see the thin-relative.test testcase.) The behaviour to rewrite these paths was added in 451c2ef199e9c5163007ac32e2d426fbfb37e664; it is unclear why it was chosen to do the rewriting for non-thin archives as well. This quirk is even pointed out in a code comment - but neither the code review at https://reviews.llvm.org/D57842 nor the linked bug report at https://crbug.com/41440160 mentions why this is done for all archives, not only thin ones. Therefore, assume that this only was done out of convenience, and change llvm-lib to not adjust the paths for non-thin archives. Normally, the actual member names doesn't matter for non-thin archives; however for short import libraries, where each member is named e.g. "foo.dll", the names do matter. If using llvm-lib to merge two import libraries (as a non-thin library), preserve the original names rather than making the member names relative.