[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building latest snapshot[with Cygwin]

"David J. Fiddes" wrote:

> Hi,
> As an excercise I tried to build the latest RTEMS using Cygwin Beta 20.1 on
> a new Celeron 466 that had never seen Cygwin before. It worked OK for
> m68k-rtems but choked on m68k-rtemself. This is roughly what I did:
> Setting up Cygwin:
> 1) Install Cygwin to e:\cygnus
> 2) Add SET CYGWIN=binmode and SET HOME=/home in cygwin.bat
> 3) Run up Cygwin shell and "mount -b e:\\unix /" and "mount -b e:\\cygnus
> /cygnus"
> 4) Created /bin, /tmp, /home /source and /build directories
> 5) Rename sh.exe to sh.exe.old and copy bash.exe to sh.exe and to
> /bin/sh.exe
> 6) Build make-3.77 and manually copied and stripped make.exe to cygwin bin
> directory
> 7) Downloaded and unpacked Cygwin perl 5.005_03.
> 8) Created ~/.bashrc with "export
> PATH=/cygnus/cygwin-b20/H-i586-cygwin32/bin:/gcc-m68k/bin:/usr/local/bin"
> and restarted shell to make Perl available and eradicate DOS paths.
> 9) Configured, built and installed autoconf-2.13 and automake-1.4
> with --prefix=/cygnus/cygwin-b20
> and --exec-prefix=/cygnus/cygwin-b20/H-i586-cygwin32
> Building the toolset:
> 1) Unpack gcc-2.95.1, binutils-2.9.1 and newlib-1.8.1 into /source
> 2) Patch with RTEMS patches as per usual
> 3) configure, build and install binutils with --prefix=/gcc-m68k
> and --target=m68k-rtems(elf)
> 4) Link ../newlib-1.8.1/newlib and libgloss with newlib and libgloss in
> gcc-2.95.1 directory
> 5) Remove libchill, libobjc, libf2c, gcc/f, gcc/ch, gcc/objc, gcc/java from
> gcc.
> 6) Configure gcc with --with-newlib, make with "make -k cross" (it choked
> for me on all-target-libiberty) and make -k install (I was too lazy to
> install texinfo like I normally do).

* I have to use --with-sys-includedir=... on linux, otherwise fixincludes seems
to perform weird things (It tries to fix the host include files for the target
- e.g. /usr/X11R6/include).
* make LANGUAGES="c c++" also builds the java compiler (gcj).

> Building RTEMS:
> 1) Set CC=gcc with "export CC=gcc"

AFAIS there is a bug in autoconf's interaction of AC_EXEEXT and AC_PROG_CC.

AC_EXEEXT apparently sets CC=cc and AC_PROG_CC at first tries to examine CC,
which previously has been set to CC=cc.  AFAIS, this is doomed to fail if you
don't have cc[.exe] in $PATH.

I would suggest that you might carry out 2 experiments:

1) Make sure that you have cc[.exe] in $PATH (evtl. copy gcc[.exe] to cc[.exe])
and try again
2) swap AC_EXEEXT and AC_PROG_CC in tools/build/configure.in (requires to have
autoconf and automake installed) and try to rebuild.

> 2) Configure RTEMS with
> configure --target=m68k-rtems(elf) --enable-rtemsbsp=gen68360 once I'd
> remembered about the CC=gcc hack it worked as per usual.
> 3) Ran make....after all the usual collection of target compiler check
> semi-failures it actually started building stuff. I ran out of time and had
> to go home so I stopped the build half way through the networking I think.
> The only unknown failure I came across was that m68k-rtemself failed during
> the make time configure when it first tried to see if the compiler worked.
> The configure just stopped dead and hung Cygwin... Haven't investigated what
> caused this yet. Plain old m68k-rtems worked just fine.
> I've just remembered the --print-file-name hack that we had to put in to
> support Cygwin pre-4.0. This can definitely be removed *if* we are moving to
> gcc-2.95.x for the target compiler.

It already is removed in the snapshot. We now use automake rules in automake
converted directories and use analogous rules for pure autoconf directories
(cf. make/directory.cfg).

> It can be removed from host stuff *if*
> we make Cygwin users move to gcc-2.95.1 as their main compiler (a move that
> official Cygwin will make in a while anyway).

What do you think should be removed? We only have kept some print-file-name
related parts in some files for backward compatibility reasons.

> Another hack that was added at
> about the same time is that cygwin doesn't support --pipe. As of Beta 20.1
> and egcs-1.1b it does. Not a major thing but worth a cleanup.

The configure scripts contain a check to detect this. IIRC, it didn't work on
cygwin and we had to bypass it.

You can try to do this:
* remove the 2 lines refering to cygwin in aclocal/gcc-pipe.m4
* run autogen from the toplevel source directory to regenerate the configure
* try to check if it works by rebuilding RTEMS

BTW: is the path separator problem (\\ vs. / -- cf. GCCSED problem) solved with
Cygwin? If yes, I would like to remove related parts in RTEMS.

> With the number of target compiler checks made during an RTEMS build now
> quite large the "Terminate" dialog is really bugging me.

Does this also happen in the tools/build directory?

> I'm going to give a
> new cygwinb1.dll a go then try hacking cygwin myself to add a check that the
> EXE being passed to CreateProcess() starts with either MZ, NE or PE. It may
> be dirty but it should serve our purpose.

I am not sure if this is related to your "Terminate" problem, but I see some
target compilers segfaulting in target compiler checks under linux.

IMO, this is due to bugs in the default linker scripts used for rtems cross
compilers (invalid symbol "start" and similar, cf the config.log files inside
the directories where this happens). Esp. building for --i386-rtems[elf] leaves
a core file in every directory a configure script is run, however the
m68k-rtems compilers do not seem to be affected.