Cross-compiler for "i386-pc-linux-gnu" on WIN-NT thru Cygwin

Manoj Verma
Sat Jan 5 09:21:00 GMT 2002

Hi David,
Any info about the following error (While biulding glibc-2.2.4) :
mv -f /cygdrive/d/cyg_i386_install/cbuild-i386-glibc-2.2.4/sysd-syscallsT
'BEGIN { subdirs = ""; inhibit = "" };                  \
/^#/ { next };                                          \
/^[^-]/ { subdirs = subdirs " " $0 };                   \
/^-/ { inhibit = inhibit " " substr($0, 2) };           \
END { printf "sysdep-subdirs =%s\n", subdirs;           \
      printf "sysdep-inhibit-subdirs =%s\n", inhibit;   \
      print "sysd-dirs-done = t" }'                     \
       /dev/null linuxthreads/sysdeps/pthread/Subdirs
sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs > /cygdrive/d/cyg_i386_i
BEGIN { subdirs = ""; inhibit = "" };                    /^#/ { next };
/^[^-]/ { subdi
rs = subdirs " " $0 };                   /^-/ { inhibit = inhibit " "
substr($0, 2) };           END { printf "sysdep-subdirs
 =%s\n", subdirs;                printf "sysdep-inhibit-subdirs =%s\n",
inhibit;         print "sysd-dirs-done = t" }: not fo
make[1]: ***
[/cygdrive/d/cyg_i386_install/cbuild-i386-glibc-2.2.4/sysd-dirs] Error 127
make[1]: Leaving directory `/cygdrive/d/cyg_i386_install/glibc-2.2.4'
make: *** [all] Error 2
Is this because of the following combination I am using, as you said before:
	>	binutils-2.11.2
	>	gcc-2.95.2
	>	glibc-2.2.4

or there is different reason altogether?

Thanks in advance,

-----Original Message-----
From: David Korn []
Sent: Thursday, January 03, 2002 8:58 PM
To: Manoj Verma
Cc: Crossgcc-List (E-mail)
Subject: RE: Cross-compiler for "i386-pc-linux-gnu" on WIN-NT thru

   Hi Manoj,

>actually I have the following configuration:
>	binutils-2.11.2
>	gcc-2.95.2
>	glibc-2.2.4

  I have two recommendations about this:

1) I have had trouble using binutils 2.11.x with gcc 2.95.x; I think this
is because it was changed in a way that was co-ordinated with new features
needed by gcc-3.0.x, but backward compatibility was broken.  I would always
use binutils 2.10 or even 2.9 series with gcc 2.95.x

2) Also, gcc 2.95.2 is out of date; 2.95.3 is basically the same, but has
some tricky bugs fixed in the optimizer.  I'd recommend it in preference
to 2.95.2.

  However, if your current toolchain is working ok for you, you might be
happy enough to leave things as they are until and unless problems actually
show up.

>while building using "make all 2>&1 | tee mymake.log" I am getting the
>following error:
>In file included from sysdeps/unix/sysv/linux/sys/syscall.h:25,
>                 from sysdeps/unix/sysdep.h:21,
>                 from sysdeps/unix/i386/sysdep.h:19,
>                 from sysdeps/unix/sysv/linux/i386/sysdep.h:24,
>                 from :1:
>/cygdrive/c/Cygwin_Install/usr/include/asm/unistd.h:295: badly 
>parameter list in `#define'
>/cygdrive/c/Cygwin_Install/usr/include/asm/unistd.h:307: badly 
>parameter list in `#define'

  OK, without actually having a copy of your unistd.h to look at, I have
to guess a bit here, but what I think is the problem here is that the
various parts of your system are mismatched.  Gcc-2.95.2 is fairly old now,
glibc-2.2.4 is very recent, and I'd imagine that your linux kernel sources
are somewhere in between.  It looks to me as if the more recent glibc and
linux kernel sources that you are using makes use of some of the new C
language features that have only recently been added to gcc-3.0.x.

  Gcc-3.0.x is compatible to the C99 language standard, and includes new
features such as macros with variable argument lists.  My guess is that this
feature has been used on lines 295 and 307 of unistd.h (which I think comes
from your linux kernel headers).

  So I think the problem is most likely that your linux kernel source (and
perhaps your glibc source too, I don't know) is too recent: it uses features
from gcc-3.0.x, and you won't be able to make it work with 2.95.2.  You
should do some research, because if the linux kernel people decided to
make the kernel depend on using gcc-3.0 in a non-backward-compatible way (as
seems to be the case) then they would probably have made a readme about it
somewhere in the source code, or perhaps in the ChangeLog file.

  If I'm right, then it's up to you to decide whether you will be satisfied
with slightly older versions of the kernel code, or whether you will be
forced to use gcc-3.0,x instead of 2.95.x.

   hope this helps,
Burn your ID card!
Help support the campaign, copy this into your .sig!

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list