[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Building latest snapshot[with Cygwin]
- Date: Wed, 1 Sep 1999 22:18:34 +0100
- From: D.J at fiddes.surfaid.org (David J. Fiddes)
- Subject: Building latest snapshot[with Cygwin]
> * 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).
Hmm. I'll give this a go and see what it yields but I don't think that it
causes a problem on Cygwin. Of course because Cygwin uses newlib as it's
libc the effects of a fixincludes going banannas might be less apparent.
> * make LANGUAGES="c c++" also builds the java compiler (gcj).
I cheat and just delete the objective C, java, chill and fortran compilers
from the source tree before configuring. It has saved me a lot of hassle
with Cygwin back when it choked on non-C/C++ compilers even for native use.
> 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
I symlinked cc to gcc and tried it. It does indeed start working.
> 2) swap AC_EXEEXT and AC_PROG_CC in tools/build/configure.in
> (requires to have
> autoconf and automake installed) and try to rebuild.
This also works. The configure output looks like the same order as egcs and
other atoconf packages now... I've only just noticed this, honest!
> > 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).
Anything that sed'ed the output of gcc thinking it was going to be fed a DOS
path. The silly code that was *purposefully* put in gcc.exe to do this was
removed by Mumit Khan at some point in the egcs-1.2 development effort. This
is the only program I know of that output DOS path information. The rest
have been "clean" for some time.
> 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
I've done this. Just waiting to see the results(got to wait for a compiler
to finish building first).
> BTW: is the path separator problem (\\ vs. / -- cf. GCCSED
> problem) solved with
> Cygwin? If yes, I would like to remove related parts in RTEMS.
See two paragraphs back (I think) ;)
> > 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?
No checks for host/non-cross binaries work just fine which is why the Cygwin
guys haven't trapped this problem. I don't think that eCos does this check
which is why it hasn't been added to Cygwin. BTW, As far as I can tell eCos
is a major Cygwin driving force...
> 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.
Depends. I'm not sure how picky ELF executables are about which OS they are
running on. Can a Linux ELF EXE be distinguished from say a Be EXE or
i386-rtemself EXE? If not then this is exactly the same problem. I doubt
this is the case though. The reason it fails on NT is because NT is trying
to support an "object file format" that makes a.out look like spaceship
technology. If NT were checking for different flavours of PE-COFF EXE it
would have no difficulty distinguishing between say Alpha and x86...except
that non-x86 ports of NT have been ditched :(
I tried a couple of interesting upgrades to the setup I was using yesterday.
I tried using Mumit Khan's gcc-2.95 native Cygwin binaries which didn't seem
to affect anything (except for the DOS paths issue). I also tried updating
the Cygwin shell to bash-2.03 which didn't seem to break anything..it also
didn't fix anything. However when I tried the latest cygwin1.dll snapshot
something did change. The unwritable cache problem disappeared. Obviously
what ever bug was causing that is now fixed....
By my rekoning the only remaining bug is this damn illegal EXE problem but
I've just found the lines of code that matter. Just need to build and test
my fix....then we might have a 100% working Cygwin setup. whoopee!