As far as i know this is all due to PATH, and should also be independent of
the fact if it’s invoked from python or directly in the shell.
DLL not found errors actually arise from them not being available, although
you can also screw yourself with dlls with the same name but wrong
architecture (although you’d probably get symbol errors then).
a) 32 bit msys is no different than the 32 bit packages in 64 bit msys, in
fact it’s just the 64 bit part missing
b) You . They are pure Windows executables in the sense that don’t require
an emulation layer (cygwin, msys2-base) to run but directly use the windows
API.
c) You don’t need static, but the libraries it errors about (you can also
check with ldd or depends.exe → google).
To conclude this, i just installed the 32 bit toolchain, i have
mingw64/bin/ in my path, started python3 from a windows command prompt and
successfully ran subprocess.run('D:/msys64/mingw32/bin/g++')
I think you may have too much in your path.
Then again you also didn’t specify if you had dll not found or symbol
errors.
On Sun, Apr 1, 2018 at 1:01 PM Brendan Simon (eTRIX) <
brendan.si...@etrix.com.au> wrote:
> I'm new to MSYS2 and first time on the mailing list ("Hi!"),
>
> I have installed MSYS2 (x86_64) and install various packages to be used
> with a Jenkins CI system. Basically Jenkins clones a branch from a local
> git repo, then runs a DOS batch file (yes, I know !!), which sets up some
> environment variables for Embarcadero and IAR compilers, then calls a
> custom python script to run unit tests and coverage (gcov).
>
> The python script is invoked with `c:\msys64\mingw64\bin\python3.6m.exe`.
> It then builds some unit tests using mingw64-gcc,
> `c:/msys64/mingw64/bin/g++.exe`, via python's `subprocess.run()`
>
> This works ok, but I decided that all our production compilers are 32-bit,
> so it would make sense to run the unit tests with a 32-bit compiler too.
> So I changed the the compiler command to: `c:/msys64/mingw32/bin/g++.exe`,
> which FAILS to run !! DLL errors (`libwinpthread*`, etc).
>
> If I invoke the 32-bit python executable
> (`c:\msys64\mingw64\bin\python3.6m.exe`) then all is good, but of course I
> can't run 64-bit programs (e.g. `c:/msys64/mingw64/bin/g++.exe`), as I get
> the same errors as before, presumably for the same reasons.
>
> Also, when I used a 64-bit g++ with 64-bit python, the resultant
> executable wouldn't run, again due to DLLs. I had to use `-static` linker
> option to get it to run. Setting the PATH didn't seem to help.
>
> I can live with using 32-bit Python, however I'd like to understand what
> is going on.
>
> (a) I presume I would be better off installing the i686 version of MSYS2,
> and only using mingw32 bit subsystem. yes?
>
> (b) When running the mingw64 Python (from a DOS prompt), why can I not
> invoke a mingw32 executable (e.g. `g++`) from that python script (and vice
> versa) ?
> Both the mingw32/64 bit python and other executables are supposed to be
> pure Windows executables and independent of MSYS2, aren't they?
>
> (c) Why do I need to use the `-static` linker option to run a program I've
> built? What libraries do I need in my path and how do I set library
> paths? Iis it just PATH or something else? PATH didn't seem to work for
> me!
>
> Thanks, Brendan.
> --
> ------------------------------
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Msys2-users mailing list
> Msys2-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Msys2-users mailing list
Msys2-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/msys2-users
