[PATCH 2 of 2 STABLE] setup: search for proper library name on MinGW/msys2
yuya at tcha.org
Wed Apr 27 09:35:11 EDT 2016
On Tue, 26 Apr 2016 16:25:56 -0700, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1461712815 25200
> # Tue Apr 26 16:20:15 2016 -0700
> # Branch stable
> # Node ID a42a7f71b89a026572f8ce798fa2c2bbaf6dea3a
> # Parent ba89075c616d56c3f1ce02c97103c6d0ff8aa006
> setup: search for proper library name on MinGW/msys2
> Attempting to build Mercurial from source using MinGW from
> msys2 on Windows produces a hg.exe that attempts to load e.g.
> python27.dll. MinGW prefixes its library name with "lib" and
> adds a period between the major and minor versions. e.g.
> Before this patch, hg.exe files in a MinGW environment would
> either fail to find a Python DLL or would attempt to load a
> non-MinGW DLL, which would summarily explode. Either way,
> hg.exe wouldn't work.
> This patch changes builds so hg.exe produced by MinGW will
> search for "libpythonX.Y" instead of "pythonXY" in hopes that
> MinGW will find a matching library.
> It is certainly possible to build Mercurial in a MinGW environment
> but want to load against a non-MinGW Python. This patch will
> likely break that configuration. I build the Mercurial wheels in
> cmd.exe (not MinGW) so this doesn't impact me. I'm not sure what
> other packagers do on Windows. If we need the ability to build under
> MinGW but targeting the traditional library name, we can likely
> make that configurable.
I'm not a packager, but this will break my Windows test environment. I
use MSYS or MSYS2 with Windows Python because I just want a sane shell
and ssh into Windows.
If python is not a MSYS python, setup.py will generate a normal win32
executable, which should be linked to python27.dll.
More information about the Mercurial-devel