Re: system error 14001 and vcredist_x86.exe

["Paul Moore" <p.f.moore@...>]

On 07/08/2008, Peter Odding <xolox@home.nl> wrote:
> Not to be the pessimist I always am, but this almost seems to rule out
> binary distribution of *independent* plug-ins for the Windows platform.
> Surely this problem must have been solved already for Perl, PHP, Python,
> etc?! I can't believe it's the same mess over there :)

With Python, the standard Python binaries are shipped to dynamically
link to MSVC (currently only MSVCR71, so they only hit the fun in the
2.6 betas at the moment - but I believe things work OK there...)

All binary extensions are built with distutils, which enforces linking
to the same CRT as the main executable. Distutils includes recipes to
support MSVC and mingw, and various Unix/Mac compilers - nothing else
is (technically) supported or (in practice) used.

There are 2 problems Lua has that Python doesn't need to deal with:

1. Lua has no standard build process - distutils makes things MUCH
easier in Python (pre-distutils, the picture for Python binary
distributions was also a bit of a mess, and that was in MSVCRT,
pre-assembly days).
2. Lua explicitly supports embedding, and as such has to deal with not
being the host app, and hence not being able to dictate which CRT is
used here. Python technically supports embedding, but in practice few
people do it, and I don't know if it's well-tested for this type of
issue.

I'd suggest 2 practical ways forward:

1. Develop a standardised "extension building" package for Lua. Maybe
LuaRocks is (or could be) this, I don't know, but it's certainly true
that many packages do not currently use it for builds (a mixture of
makefiles and MSVC project files seems common).

2. Standardise a process for binary loading in embedded Lua. Maybe
have a protocol for ensuring that loadable modules match the CRT used
by Lua (say, by a DLL naming convention), or maybe something more
complex (which would need the expertise of people more familiar with
CRT hacking than me). Or maybe even something as simple as
standardising on (and enforcing, somehow) only using MSVCRT in
embedded situations (which seems to work, although it requires Mingw
rather than MSVC).

The big issue here is that it's about standardisation. Nothing will
really work until everyone uses it. And that's a community issue. The
various threads here show that people understand the need, but will
they change how they work to follow a new standard? Particularly
developers on Unix, who don't have the issue and so have to change
their build processes for no benefit to themselves.

Paul.