Hi Norbert,
Thanks for your reply. I do have a whole lot of stuff in my path, set
by various application installers. BTW, I'm running Windows 10 Pro.
I open a DOS Prompt and set the path. I first prepended
`c:\msys64\mingw64\bin`, and that didn't work.
I then prepended `c:\msys64\mingw32\bin`, and that didn't work.
I then prepended `c:\msys64` (as that had previously helped when running
`g++` from command prompt), but that didn't help either.
The start of my path looks like this:
PATH=c:\msys64:c:\msys64\mingw32\bin:c:\msys64\mingw64\bin:
I run python from DOS prompt with:
C:\Users\brend>c:\msys64\mingw64\bin\python3.6m.exe
>>> import subprocess
>>> r = subprocess.run( [ 'c:/msys64/mingw64/bin/g++', '-Wall', '-o',
'hello64.exe', 'hello.cpp' ], cwd='c:/msys64/home/brend' )
>>> r.returncode
0
The exe built and runs ok :)
Now try to build with mingw32 (running in the same mingw64 python session).
>>> r = subprocess.run( [ 'c:/msys64/mingw32/bin/g++', '-Wall', '-o',
'hello32.exe', 'hello.cpp' ], cwd='c:/msys64/home/brend' )
I get a Windows dialog pop up with the message:
cc1plus.exe - Application Error
The application was unable to start correctly (0xc000007b).
Any suggestions?
Does it make a difference in the order of the mingw32/64 paths?
Do I need paths set as a system environment variable?
Thanks, Brendan.
------------------------------------------------------------------------
On 1/04/2018 11:05 PM, Norbert Pfeiler wrote:
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 <mailto: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
<mailto: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
