Problem configuring RTEMS for m68k (Cygwin)

[Stephan Merker]

----- Original Message -----
From: "Ralf Corsepius" <corsepiu at faw.uni-ulm.de>
To: <joel.sherrill at OARcorp.com>
Cc: "Stephan Merker" <merker at decrc.abb.de>
Sent: Sunday, December 17, 2000 7:37 AM
Subject: Re: Problem configuring RTEMS for m68k (Cygwin)


> Joel Sherrill wrote:
> >
> > Stephan Merker wrote:
> > >
> > > The problem was not the linker warning but that Cygwin crashes when
the m68k
> > > program is executed. A workaround is to rename the program from
conftest.exe
> > > into e.g. conftest.pgm.
>
> The related autoconf test is based on being able or not to run
> programs. Renaming conftest.exe into conftest.pgm just tells Cygwin
> that this is not an executable, and therefore fools autoconf by
> telling it "everything is cross-compilation".

That's not true. I looked into the Cygwin sources (winsup\cygwin\spawn.cc).
If a process is to be spawned, the file name is analysed. If it has the
suffix .exe, .com, or .cmd, the file is executed immediatly (even if the
file has no valid executable file format). For files with other suffixes,
cygwin analyses the file. If the file starts with the famous 'MZ', it is
passed to CreateProcess (i.e. it is executed). Otherwise, cygwin assumes
that the file is a shell script and passes it to the shell (to /bin/sh.exe
or the one specified by #!...).
I.e., when building RTEMS for m68k, conftest.pgm is passed to the shell
which complains immediatly. When building RTEMS for Cygwin, conftest.pgm
would be normally executed (but for Cygwin I don't rename the program). You
can try it out with a simple 'Hello World' program:
  gcc hello.c
  mv a.exe a.pgm
  a.pgm

>
> > > Cygwin starts a .exe file without looking at it which leads to the
crash.
> > > Files not ending in .exe are checked whether they are executable
(starting
> > > with 'MZ') or if they are shell scripts. M68k programs are considered
to be
> > > shell scripts and the shell returns with an error code 2, that is then
> > > interpreted by configure.
> > >
> > > A patch in aclocal/prog-cc.m4 does the renaming. However, I'm not yet
> > > through with testing.
> >
> > Hmmm..  didn't we fight this same problem a while back?
>
> I think so, a fairly long time ago, approximately the time when the
> eariest public Cygwin betas were out (~when Geoffroy Montel was
> active on RTEMS).

I found one entry in the Cygwin mailing list about exactly the same problem.
The proposed workaround was to patch spawn.cc to check all files for 'MZ'
before they are executed. But I prefered a solution without patching Cygwin.

>
> >  Do any of you
> > remember the solution then?
> IIRC, Dave Fiddes at that time provided a binary Cygwin-fix for
> this, but though I can't recall having changed anything in RTEMS
> because of this, I also can't exclude it.
>
> > Ralf.. is this something reintroduced with the move to using more
> > standard automake conventions.
> Let me put it this way: I do not understand why Stefan is
> experiencing this problem and others apparently do not. If this
> really is a general problem, I would expect rtems-list to be overrun
> with related reports.

In fact, this is strange. Maybe the reason is, that I'm using an up-to-date
Cygwin. AFAIK, there are some special cygwin1.dll versions around, that were
'prepared' for RTEMS (maybe they include the spawn.cc patch).

>
> Are you able to reproduce it with your Cygwin/Rtems installation?
> [Though I am now also having a native Cygwin toolchain, I do not
> have any Cygwin-cross-Rtems toolchain installed.]
>
> What I see from Stefan's original posts to rtems-list@ seem to be
> symptoms of not using the correct cc to me, ie. either (in
> decreasing likelyhood):
> * Having set CC
no

> * Not having cc.exe (missing link from gcc.exe to cc.exe)
I have (cc.exe is linked to the native gcc.exe, not the the cross gcc).

> * Not having set up $PATH correctly.
Well, you never know. But at least all tools are found.

> * Not having deleted the remains from failed configuration attempts
> when rerunning configure.
I delete the whole build directory before running configure.

> * Having mixed up with host, target and build.
At least the configure output looks reasonable.

> * text vs. bin mode mounting.
I'm using bin mode mounting. I hade some problems with DOS EOLs because of a
bug in Cygwin's patch.

>
> Another alternative could be not using the correct version of
> autoconf (RTEMS requires autoconf-2.13, versions above will not work
> at present time).
I'm using autoconf 2.13

> As you know, the RatHeds have a tendency to push beta-versions into
> releases, so I would not be surprized if this had happened again.
>
> Ralf
> --
> Ralf Corsepius
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
> (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
> http://www.faw.uni-ulm.de
>

With the workarounds described above, I can build RTEMS for Cygwin (posix
BSP) and for M68k (efi332 BSP) using a standard Cygwin, that i'm updating
every week or so.
Btw, I have also the POSIX API of RTEMS running on top of the Posix BSP
built on Cygwin using a wrapper DLL for cpu.c. The POSIX tests run through
(without the IMFS related tests). I will post a patch file as soon as it is
finished (should be in this week).

Stephan