It worked ok if I used the msys python
(`c:\msys64\usr\bin\python.exe`). I could build both mingw32 and
mingw64 exes.
I just noticed my path had `:` instead of `;` to separate the paths.
Fixed that, but I still had the same issue.
I found I could get both to compile under the following situations.
set path to `c:\msys64\mingw32\bin` and invoke python with
`c:\msys64\mingw64\bin\python3.6m.exe`
However, I could only run the 32-bit version (due to the path).
set path to `c:\msys64\mingw64\bin` and invoke python with
`c:\msys64\mingw32\bin\python3.6m.exe`
However, I could only run the 64-bit version (due to the path).
So how can I run both mingw32 and mingw64 executables, without having
*both* mingw32\bin and mingw64\bin in the path?
Why do I need to have mingw32\64 in the path. I thought mingw binaries
only need standard windows libraries? (doesn't seem to be the case).
Thanks, Brendan
------------------------------------------------------------------------
On 1/04/2018 11:47 PM, Norbert Pfeiler wrote:
just don’t put both 32 and 64 bit in your path because the libraries
and executables have the same name in both prefixes
python start without the path set, for example
On Sun, Apr 1, 2018 at 3:36 PM Brendan Simon (eTRIX)
<brendan.si...@etrix.com.au <mailto:brendan.si...@etrix.com.au>> wrote:
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
