i used the wrong address, see below
On Sun, Apr 1, 2018 at 4:31 PM Norbert Pfeiler <norbert.pfei...@gmail.com>
wrote:
> >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
