rtems-source-builder on cygwin/64

[Chris Johns]

On 12/03/2015 4:59 am, emanuel stiebler wrote:
> On 2015-03-11 18:40, Joel Sherrill wrote:
>>
>>
>> On 3/11/2015 12:12 PM, emanuel stiebler wrote:
>>> Hi all,
>>> should it work at the moment?
>> Since Chris is likely the best one to answer that and he won't be
>> online for at least a a few hours, give it a try. You will know the
>> answer before he wakes up. :)

I do not test cygwin but will accept patches if they look ok.

I invested a large amount time last year attempting to get cygwin to 
build native tools and gave up. I just could not get anything close to 
stable and then I really had no idea what I had got cygwin to actually 
install (I suspect that is just my lack of knowledge). I am not sure 
about building cygwin hosted versions of the tools.

I have always built and used native Windows tools and up until recently 
I have been using a Canadian cross (Cxc) build on FreeBSD. Native 
Windows tools run at the best possible speed on Windows because there is 
no POSIX emulation layer and they integrate into other Windows tools, 
such as IDEs, because the paths used are standard Windows paths. When 
combined with waf as a build system the overall performance and 
stability is excellent.

I have recently just pushed changes into the RSB to support MSYS2 and I 
am in the process of updating the RSB documentation to outline what you 
need to do. I have been able to build an ARM compiler tool chain on 
Windows using MSYS2 and this is first for many years. It take a while so 
please be patient. The doco update is:

------
MSYS2

This is a new version of the old MinGW project's original MSYS based 
around the Arch Linux pacman packager. MSYS and MSYS2 are a specific 
fork of the Cygwin project with some fundamental changes in the handling 
of paths and mounts that allow easy interaction between the emulated 
POSIX environment and the native Windows environment.

Install MSYS2 using the installer you can download from 
https://msys2.github.io/. Follow the instructions on the install page 
and make sure you remove any global path entries to any other Cygwin, 
MinGW, MSYS or packages that may uses a Cygwin DLL, for example some 
ports of Git.

To build the tools you need install the following packages using pacman:

  $ pacman -S git cvs bison make texinfo patch unzip diffutils tar \
           mingw64/mingw-w64-x86_64-gcc mingw64/mingw-w64-x86_64-binutils

To build make sure you add '--without-python --jobs=none' to the 
standard RSB command line. MSYS2 has a temp file name issue and so the 
GNU AR steps on itself when running in parallel on SMP hardware which 
means we have to set the jobs option to none.

Install a suitable version of Python from http://www.python.org/ and add 
it to the start of your path. The MSYS2 python does not work with waf.
------

Finally there are a couple of issues we are looking into:

1. The gdb-7.8.2 does not build for Windows. We need gdb-7.9 however 
some local RTEMS patches need updating before we can switch all targets 
to that version. The ARM target has been switched.

2. Building rtems-tools, which happens when building the tools, is 
failing for some Windows users. The RTEMS ticket #2205 details the 
issue. If you can add anything please do.

>
> I'm on cygwin, and it sits after just few hundred lines in
>
> /bin/sh ./libtool --silent --mode=link gcc -O2 -pipe
> -I/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/include
> -std=gnu99 -I./lib -I. -g -O2 -Wall -Wmissing-prototypes
> -Wstrict-prototypes -fexceptions  -DHAVE_EXPAT_CONFIG_H -no-undefined
> -version-info 7:0:6 -rpath /opt/rtems-4.11/lib
> -L/cygdrive/d/_home/emu/RTEMS.Work/rtems-source-builder/rtems/build/tmp/sb-emu/4.10/rtems-arm/opt/rtems-4.11/lib
> -o libexpat.la lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
>
> and cpu usage goes back to 0% ...
>

At a guess this looks like a make issue with the -j option which is the 
default for the RSB. try '--jobs=none'. I have observed both MinGW MSYS 
and Cygwin suffer from incorrect handling of the wait status returned 
from fork calls in make which results in make stalling and this happening.

Chris