On Sat, 24 Feb 2024 10:00:21 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>>> And then I think this will actually help Julian, since we'll push the >>> microsoft strangeness away in a separate file >> >> Thanks! Though I do first need to rebase on top of it and fix all the merge >> conflicts first... >> (Thinking about it, this likely means I have to excise some of the Microsoft >> linking logic out into the "regular" linking file since some of the >> Microsoft linking process is used by Windows linking in general, even with >> the gcc toolchain) >> >> Just a comment: Why not reuse the AR variable for lib rather than introduce >> an entirely new LIB variable? The logic treating lib.exe as ar is gone with >> this change, but that doesn't mean they have to be split into entirely >> different variables. LinkMicrosoft could just run $($1_AR) without treating >> it as ar. This saves one autoconf and Makefile variable > >> Why not reuse the AR variable for lib rather than introduce an entirely new >> LIB variable? > > The reason will become more apparent as I progress towards proper handling of > static libs. In short, AR is not by far a 1-to-1 mapping with LIB. On > non-Microsoft toolchains, we are basically going to do static linking by ld + > objcopy + ar; on Windows, it's just lib. So there is nothing to be gained by > pretending that lib is ar. > @magicus This pull request has not yet been marked as ready for integration. That last second save is nothing short of impressive haha ------------- PR Comment: https://git.openjdk.org/jdk/pull/17987#issuecomment-1963966880
