On 5/5/20 5:01 pm, Sebastian Huber wrote:
On 05/05/2020 08:57, Chris Johns wrote:
On 5/5/20 4:05 pm, Sebastian Huber wrote:
On 05/05/2020 08:01, Chris Johns wrote:
What does `os.uname()` return?
In the msys shell:
$ python
Python 3.7.4 (default, Jul 11 2019, 09:35:14)
That is what I have installed.
[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.uname()
posix.uname_result(sysname='MSYS_NT-6.1-7601', nodename='Blub',
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC',
machine='x86_64')
I have ...
>>> os.uname()
posix.uname_result(sysname='MINGW64_NT-10.0-18362', nodename='weng',
release='3.0.7-338.x86_64', version='2019-07-11 10:58 UTC',
machine='x86_64')
I have never seen `MSYS_NT` before.
I am running Window-10 on real hardware running Version 1903, OS
build 18362.778. I have not picked up the feature update yet. I am
remote to the machine and do not want to try.
I did the testing on a more or less retired Windows 7 VM. I will
setup a Windows 10 VM.
Oh OK, maybe keep it? Could you patch the RSB and see if it works?
I removed the GDB from the build set.
I am pretty sure it would work with a patched windows.py.
It is currently busy building the
5/rtems-sparc build set (without GDB) in a mingw64 shell. Is a build in
the msys shell something useful/supported?
Yes, we have valid users. Plus building on Windows is valid for the same
reasons we build from source on all hosts maybe more so.
I normally build the mingw64 tools on Linux.
There is Cxc support in the RSB but I have not maintained it recently, I
see it as a dead end. I would not use those tools in a production
environment unless I checked every aspect of them so the runtimes are
aligned. It is easy to become wedged in dll hell. I learnt this lesson
on Fedora decades ago and gave up.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
