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> 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> 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
