Windows Command Prompt Can't Create Archives

[everythingfunctional]

Running in a Windows Command Prompt, I get the error:

'ar' is not recognized as an internal or external command,
operable program or batch file.

which is not surprising, but I'm not sure what the correct command would be on Windows for creating archives for libraries.

[everythingfunctional]

According to this stackoverflow answer, it is link.exe -lib.

[awvwgk]

It might also depend on the availability of MinGW or Cygwin type libraries. I would be interested in how compatible an archive created by link.exe is on a Cygwin Posix layer. For the setup we have on the GitHub Windows runner there is a wild mixture of MSYS2, git-bash and choco packages in the PATH, not sure which of them is providing the ar binary we are using to create the archive.

[arjenmarkus]

My first reaction was to write "they are incompatible", but a quick check showed that the same file structure is used. I listed the contents of a library file that was created with the Intel compiler on Windows using Visual Studio, in a Cygwin command window, using ar. No problem. That said, I am pretty sure that you cannot mix object files created by compilers that have not been set up to be compatible with each other. Op za 13 mrt. 2021 om 00:04 schreef Sebastian Ehlert < ***@***.***>:

…

It might also depend on the availability of MinGW or Cygwin type libraries. I would be interested in how compatible an archive created by link.exe is on a Cygwin Posix layer. For the setup we have on the GitHub Windows runner there is a wild mixture of MSYS2, git-bash and choco packages in the PATH, not sure which of them is providing the ar binary we are using to create the archive. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#384 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR2DPCTOTKYZKW3C47LTDKMYXANCNFSM4ZDCEOLQ> .

[everythingfunctional]

Started looking into this a bit, and it appears msys/mingw do have ar available, but cmd and git Bash do not. Right now our set of os types only distinguishes between OS_CYGWIN and OS_WINDOWS. It seems we should have OS_WINDOWS_CMD, OS_WINDOWS_GIT_BASH and OS_WINDOWS_MINGW.

Unfortunately it seems we will be unlikely to distinguish based on environment variables alone (at least the ones we're currently checking).

Environment	OS	OSTYPE
CMD	Windows_NT	N/A
git Bash	Windows_NT	msys
MinGW	Windows_NT	msys

Any thoughts on how to distinguish between git Bash and MinGW? Any thoughts on the names of the variables? Would OS_CMD, OS_GIT_BASH and OS_MINGW be sufficient or is that not explicit enough?

[arjenmarkus]

Plain MinGW-w64/MSYS2 command windows define an environment variable MSYSTEM: the values are MINGW32, MINGW64 and MSYS2 for the three flavours. Git bbash seems to be based on MinGW-w64/MSYS2, so you cannot distinguish it from plain MinGW. Op do 18 mrt. 2021 om 17:09 schreef Brad Richardson < ***@***.***>:

…

Started looking into this a bit, and it appears msys/mingw do have ar available, but cmd and git Bash do not. Right now our set of os types only distinguishes between OS_CYGWIN and OS_WINDOWS. It seems we should have OS_WINDOWS_CMD, OS_WINDOWS_GIT_BASH and OS_WINDOWS_MINGW. Unfortunately it seems we will be unlikely to distinguish based on environment variables alone (at least the ones we're currently checking). Environment OS OSTYPE CMD Windows_NT N/A git Bash Windows_NT msys MinGW Windows_NT msys Any thoughts on how to distinguish between git Bash and MinGW? Any thoughts on the names of the variables? Would OS_CMD, OS_GIT_BASH and OS_MINGW be sufficient or is that not explicit enough? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#384 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR3NQ4DSN4DHL4MDX2LTEIQU5ANCNFSM4ZDCEOLQ> .

[everythingfunctional]

My initial thought was that we would detect the environment and base our decision off that. But now I think we should just see if ar works, if so use it, if not try link -lib, and just fail if that one doesn't work. I'll try and see if we can tell from execute_command_line what works.

[everythingfunctional]

I tried executing the following on each OS, and checking the values of exitstat and cmdstat for each. Here's what I found.

Note: I did install something on Windows that put ar in my path on cmd prompt

command	Linux	MacOS	Windows
ar	exitstat=1, cmdstat=0	exitstat=1, cmdstat=0	exitstat=1, cmdstat=0
ar --version	exitstat=0, cmdstat=0	exitstat=0, cmdstat=0 *	exitstat=0, cmdstat=0
arr	exitstat=127, cmdstat=3	exitstat=127, cmdstat=3	exitstat=1, cmdstat=0

• Note: ar on MacOS does not support --version, so running the command ar --version actually gives exitstat=1

My conclusion then is that, only on Windows should we do the check for ar, other platforms can just assume it will be present. And if ar isn't found based exitstat from the command ar --version, we just assume link -lib will work.

I will implement the above (probably in constructing the model?) and try to test it out.