>I thought mingw binaries only need standard windows libraries?
that’s not true for any sufficiently complex program
actually – to my surprise – i just put both mingw64/bin/ and mingw32/bin/
in the path and was able to compile and run 32 and 64 bit gcc built
executables from both 32 and 64 bit python3
i wouldn’t do that tho, but instead use a wrapper script which allows you
to run either 32 or 64 bit stuff in isolation
On Sun, Apr 1, 2018 at 4:14 PM Brendan Simon (eTRIX) <
brendan.si...@etrix.com.au> wrote:
> 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> 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
