Merged
Conversation
25b0862 fixed one; this hopefully fixes all the others.
Specifying make MSVC_DETECT=0 ... overrides all of the detection logic for the Microsoft C Compiler and simply assumes that the environment is correct. This obviously means that building both 32 and 64-bit CHAINS is not possible. checkenv script added which outputs a warning if the environment appears not to include the Windows SDK, tools or the Microsoft C Runtime. The script also attempts to determine the architecture of cl.exe and so advise which CHAINS value can be built with MSVC_DETECT=0. No checking logic added to Makefile, so specifying CHAINS=msvc64 with an x86 compiler and vice versa will simply build invalid object files. Updated CHANGES and also added execute bit to findwinsdk.
The Windows Platform SDK includes a release with a CRT which falls between Visual Studio .NET 2003 and Visual Studio 2005 and which does not include the secure versions of many CRT functions, including `_putenv_s`. In `flexdll_dlopen`, the logic for selecting `setenv`, `putenv` or `_putenv_s` now correctly relies on the CYGWIN and __STDC_SECURE_LIB__ defines only. The only code change to actual code is the need to declare a variable at the start of the block to comply with C89 for the Microsoft C Compiler.
Bootstrapping flexlink from within an OCaml distribution creates a bytecode version of flexlink.
It is somewhat strange having to install .obj and .o files in a BINDIR when a LIBDIR is available. Old behaviour is preserved - so flexlink will always prefer flexdll_*.$(O) and flexdll_initer_*.$(O) from the same directory as flexlink, but if they are missing then the search path is used, as for any other object file. The default manifests must still be in the same directory as flexlink.
flexlink.opt is created by OCaml when bootstrapping FlexDLL.
Collaborator
|
Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Happy New Year! Several patches arising from recent work testing OCaml trunk on various old Visual Studio installations:
.gitattributesomitted the important normalisation of existing files (sorry!)msvcrt.dllused by the mingw ports). Corrected the#ifdeflogic to share the mingw branch with older Microsoft C compilers too. This minor adjustment enables compilation in Microsoft Visual Studio .NET 2003 and also in the Windows Server 2003 SP1 SDK (which is a pre-release Visual Studio 2005 compiler).MSVC_DETECTallows all of the complex logic for detecting both 32 and 64-bit Microsoft C compilers to be disabled in favour of just trusting the environment (as for an OCaml compilation). The bootstrapping process shortly to become an OCaml PR allows a bytecode flexlink.exe to be compiled before startingmake -f Makefile.nt world, hence.cmoartefacts may now be seen. Thecheckenvscript (which must be run manually) informs the user if it looks safe to runmake MSVC_DETECT=0 CHAINS=msvc[64] ...