Should I be able to build cross gcc 4.x on Cygwin?

Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

I've been able to build an xscale-elf-targeted GCC (and binutils and  
newlib) on Mac OS X. Now I have to do the same thing on Cygwin (ugh),  
and it doesn't work.

One thing is that Cygwin has GCC 3.4, not 4.x.

Looking around, the GCC installation notes seem to imply that 3.4 can  
build 4.x, so I'm wondering if there's something in particular I need  
to watch out for?

TIA,
Rick

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Ted Byers]

Cygwin is ALWAYS well behind.  But I have had no
problem building gcc 4.2.x using cygwin (I used gcc
3.4 to build gcc 4.2.1, and 4.2.1 to build 4.2.2).

If you need 4.2.x to do your cross build, you can
build it native first, and then do your cross build
(unless your cross compiler needs something not in
cygwin - I wouldn't know since I don't attempt
building a cross compiler).  If you want, I can post
the configure parameters I used.

HTH

Ted
--- Rick Mann <rmann@latencyzero.com> wrote:

> I've been able to build an xscale-elf-targeted GCC
> (and binutils and  
> newlib) on Mac OS X. Now I have to do the same thing
> on Cygwin (ugh),  
> and it doesn't work.
> 
> One thing is that Cygwin has GCC 3.4, not 4.x.
> 
> Looking around, the GCC installation notes seem to
> imply that 3.4 can  
> build 4.x, so I'm wondering if there's something in
> particular I need  
> to watch out for?
> 
> TIA,
> Rick
> 
> 

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Brian Dessent]

Rick Mann wrote:

> I've been able to build an xscale-elf-targeted GCC (and binutils and
> newlib) on Mac OS X. Now I have to do the same thing on Cygwin (ugh),
> and it doesn't work.

"Doesn't work" is pretty vague, we need specifics.

> One thing is that Cygwin has GCC 3.4, not 4.x.

That should not matter at all.

Ted Byers wrote:

> Cygwin is ALWAYS well behind. 

Yes, yes, snipe away.  It's easy to complain.  But have you considered
that there's perhaps a reason why we only ship 3.4 with Cygwin, a reason
that's not rooted in us being lazy?  Could it possibly be that gcc 4.x
is not yet fully functional on Cygwin?  Could it be that C++ and java
exceptions are seriously broken due to lack of shared libgcc and shared
libstdc++ and shared libjava?  That we want to switch the platform over
to Dwarf-2 from SJLJ but we aren't sure how this will work on a platform
where we can't recompile the operating system, and where Dwarf-2
unwinding will thus fail in certain circumstances?  Could it just
possibly be that we have reasons for sticking with 3.4 that don't amount
to "just haven't gotten around to it", that we would rather ship a
compiler that works rather than one that falls on its ass if you try to
throw an exception across a shared library?  Can you please stop
labeling Cygwin as gratuitously out of date for no good reason?

Brian

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Tim Prince]

Rick Mann wrote:
> I've been able to build an xscale-elf-targeted GCC (and binutils and
> newlib) on Mac OS X. Now I have to do the same thing on Cygwin (ugh),
> and it doesn't work.
> 
> One thing is that Cygwin has GCC 3.4, not 4.x.
> 
> Looking around, the GCC installation notes seem to imply that 3.4 can
> build 4.x, so I'm wondering if there's something in particular I need to
> watch out for?
> 
 Without a definition of "doesn't work," we may not be of much
assistance. Cygwin special gcc will bootstrap all more recent gcc
versions. Of course, there are Windows versions and Windows versions.
Don't expect Windows versions from over 5 years ago, or an installation
which doesn't do a clean file system or registry check, to work.  Of
course, watch out for buggy antivirus programs.  If you are building
libstdc++, you would need to remove the WERROR macros there, unless your
headers meet the criteria set.   The gcc source must be installed in a
place such that there are no spaces in the path. On some installations,
it is necessary to set HOME to the top level gcc source directory.
Other than that, build on a multi-threaded platform if you want to
finish within 8 hours.
If you find that you had forgotten necessary software components in your
cygwin installation, after installing them, start your gcc configure and
build over from scratch.  In my experience, cygwin automake is broken
with respect to gcc builds, so don't install that.

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Ted Byers]

--- Brian Dessent <brian@dessent.net> wrote:

> Ted Byers wrote:
> 
> > Cygwin is ALWAYS well behind. 
> 
> Yes, yes, snipe away.  It's easy to complain.  But
> have you considered
> that there's perhaps a reason why we only ship 3.4
> with Cygwin, a reason
> that's not rooted in us being lazy?  Could it
> possibly be that gcc 4.x
> is not yet fully functional on Cygwin?  Could it be
> that C++ and java
> exceptions are seriously broken due to lack of
> shared libgcc and shared
> libstdc++ and shared libjava?  That we want to
> switch the platform over
> to Dwarf-2 from SJLJ but we aren't sure how this
> will work on a platform
> where we can't recompile the operating system, and
> where Dwarf-2
> unwinding will thus fail in certain circumstances? 
> Could it just
> possibly be that we have reasons for sticking with
> 3.4 that don't amount
> to "just haven't gotten around to it", that we would
> rather ship a
> compiler that works rather than one that falls on
> its ass if you try to
> throw an exception across a shared library?  Can you
> please stop
> labeling Cygwin as gratuitously out of date for no
> good reason?
> 
Brian Chill.  Relax.  I only made an observation.  I
implied no criticism, and one can assume that there
are reasons for it.  Ever since I started using
cygwin, it was well behind the latest release of gcc. 
For whatever reason there may be.  I certainly said
nothing that could be interpreted as suggesting that
Cygwin is gratuitously out of date.  If anything, I
would have made the assumption that it reflected the
challenge of getting everything in it to work the way
you want it to.  Some of the issues you raise as
contributing to not proceeding yet beyond 3.4 are not
relevant to the sorts of things I do, so for what I do
with GCC, my own builds of 4.2.x suffice.
 
There is no need to get upset.  No one is criticizing
or attacking you.  Or complaining.

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

On Dec 11, 2007, at 5:43 PM, Tim Prince wrote:

> Without a definition of "doesn't work," we may not be of much
> assistance. Cygwin special gcc will bootstrap all more recent gcc

Yes, of course. I wasn't yet looking for specific guidance, just a  
general idea of how easy should it be to build under Cygwin.

I'm building gcc-4.2.2 (c & c++ only), binutils 2.17 and newlib 1.15.  
Combined build, with the following configure line:

../combined/configure --target=xscale-elf --disable-nls --with-newlib  
--prefix=/usr/local/gcc-xscale-elf --disable-newlib-supplied-syscalls


When we build, we get this:


[.....]
rm -f bfd-tmp.h
cp bfd-in3.h bfd-tmp.h
/bin/sh ../../combined/bfd/../move-if-change bfd-tmp.h bfd.h
rm -f bfd-tmp.h
touch stmp-bfd-h
make[4]: *** No rule to make target `../../combined/bfd/../include/ 
aout/ar.h', n
eeded by `archive.lo'.  Stop.
make[4]: Leaving directory `/home/davide/SharkSVN/firmware/tools/work/ 
bfd'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/davide/SharkSVN/firmware/tools/work/ 
bfd'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/davide/SharkSVN/firmware/tools/work/ 
bfd'
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory `/home/davide/SharkSVN/firmware/tools/work'
make: *** [all] Error 2

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Brian Dessent]

Rick Mann wrote:

> make[4]: *** No rule to make target `../../combined/bfd/../include/
> aout/ar.h', n
> eeded by `archive.lo'.  Stop.

This looks like an incorrectly combined tree.  Are you using the "find |
cpio"/hard link method?  Because you seem to have taken the include/ dir
from the gcc repo and not the src repo, but that will not work; you need
to properly combine them to be a union of both sets.  The src repo does
contain include/aout/ar.h but the gcc repo does not.

Brian

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

On Dec 12, 2007, at 3:03 PM, Brian Dessent wrote:

> Rick Mann wrote:
>
>> make[4]: *** No rule to make target `../../combined/bfd/../include/
>> aout/ar.h', n
>> eeded by `archive.lo'.  Stop.
>
> This looks like an incorrectly combined tree.  Are you using the  
> "find |
> cpio"/hard link method?  Because you seem to have taken the include/  
> dir
> from the gcc repo and not the src repo, but that will not work; you  
> need
> to properly combine them to be a union of both sets.  The src repo  
> does
> contain include/aout/ar.h but the gcc repo does not.

Well, after much pain to get an authoritative answer, the best I was  
able to do was a minor variant on this:

http://gcc.gnu.org/ml/gcc-help/2007-06/msg00230.html

The relevant part:

$ mkdir combined
$ cd combined
$ ln -s ../gcc-4.2.2/* .
$ ln -s ../binutils-2.17/* .
[several complaints from ln about existing links]
$ ln -s ../newlib-1.15.0/* .
[several complaints from ln about existing links]
$ cd ../..
$ mkdir testbuild
$ cd testbuild
$ ../src/combined/configure --target=xscale-elf --disable-nls --with- 
newlib --prefix=/usr/local/xscale-elf-gcc --disable-newlib-supplied- 
syscalls


(My gcc-4.2.2 was built by downloading the gcc core and c/c++ tars and  
untarring core, then c/c++)

-- 
Rick

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Brian Dessent]

Rick Mann wrote:

> Well, after much pain to get an authoritative answer, the best I was
> able to do was a minor variant on this:
> 
> http://gcc.gnu.org/ml/gcc-help/2007-06/msg00230.html
> 
> The relevant part:
> 
> $ mkdir combined
> $ cd combined
> $ ln -s ../gcc-4.2.2/* .
> $ ln -s ../binutils-2.17/* .
> [several complaints from ln about existing links]
> $ ln -s ../newlib-1.15.0/* .
> [several complaints from ln about existing links]
> $ cd ../..
> $ mkdir testbuild
> $ cd testbuild
> $ ../src/combined/configure --target=xscale-elf --disable-nls --with-
> newlib --prefix=/usr/local/xscale-elf-gcc --disable-newlib-supplied-
> syscalls

I don't like that method at all, because it does not actually combine
anything, it simply takes the include/ dir from whatever tree you last
linked it to.  In this case it looks like the include from newlib wins,
but it's not recent enough.  You want to actually combine the contents
of all the include dirs in each package, not just select one.

Try the method here instead: <http://gcc.gnu.org/simtest-howto.html>. 
This uses cpio to create hard links in the combined tree, which really
does create a union of the trees, rather than simply picking one version
of each directory to use.

Brian

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

On Dec 12, 2007, at 3:47 PM, Brian Dessent wrote:

> Rick Mann wrote:
>
>> $ mkdir combined
>> $ cd combined
>> $ ln -s ../gcc-4.2.2/* .
>> $ ln -s ../binutils-2.17/* .
>> [several complaints from ln about existing links]
>> $ ln -s ../newlib-1.15.0/* .
>> [several complaints from ln about existing links]
>> $ cd ../..
>> $ mkdir testbuild
>> $ cd testbuild
>> $ ../src/combined/configure --target=xscale-elf --disable-nls --with-
>> newlib --prefix=/usr/local/xscale-elf-gcc --disable-newlib-supplied-
>> syscalls
>
> I don't like that method at all, because it does not actually combine
> anything, it simply takes the include/ dir from whatever tree you last
> linked it to.  In this case it looks like the include from newlib  
> wins,
> but it's not recent enough.  You want to actually combine the contents
> of all the include dirs in each package, not just select one.
>
> Try the method here instead: <http://gcc.gnu.org/simtest-howto.html>.
> This uses cpio to create hard links in the combined tree, which really
> does create a union of the trees, rather than simply picking one  
> version
> of each directory to use.

Okay, I'll try that. However, two things:

1) The above technique works fine on Mac OS X (I'm about to try Fedora).
2) Doesn't the first ln take precedence? The subsequent ones fail if  
the link already exists, don't they (hence the warnings)?

Thanks for the other pointer, though.

-- 
Rick

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Brian Dessent]

Rick Mann wrote:

> 1) The above technique works fine on Mac OS X (I'm about to try Fedora).

I don't know why that is off hand.  It could be a difference between ln
in Darwin and ln in GNU coreutils.

> 2) Doesn't the first ln take precedence? The subsequent ones fail if
> the link already exists, don't they (hence the warnings)?

You're probably right, and that's exactly the problem: the include/ in
gcc is not sufficient, it only contains a small subset of what the
include/ in src contains, so that is bound to fail if the gcc one is
used.

Brian

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

On Dec 12, 2007, at 4:06 PM, Brian Dessent wrote:

> Rick Mann wrote:
>
>> 1) The above technique works fine on Mac OS X (I'm about to try  
>> Fedora).
>
> I don't know why that is off hand.  It could be a difference between  
> ln
> in Darwin and ln in GNU coreutils.
>
>> 2) Doesn't the first ln take precedence? The subsequent ones fail if
>> the link already exists, don't they (hence the warnings)?
>
> You're probably right, and that's exactly the problem: the include/ in
> gcc is not sufficient, it only contains a small subset of what the
> include/ in src contains, so that is bound to fail if the gcc one is
> used.


I used the following to make the combined dir. It seemed to work on  
Mac OS X, still trying on Cygwin. Do you see anything wrong with it? I  
have three top-level dirs: src (containing gcc-4.2.2/, binutils-2.17/,  
and newlib-1.15.0/), combined, work. My find requires no "-print" (but  
I'll use that in Cygwin).

  1643  rm -rf combined/
  1644  ls
  1645  cd src/newlib-1.15.0/
  1646  find . | cpio -pdlu ../../combined
  1647  cd ../binutils-2.17/
  1648  find . | cpio -pdlu ../../combined
  1649  cd ../gcc-4.2.2/
  1650  find . | cpio -pdlu ../../combined
  1651  cd ../..
  1653  cd work
  1654  rm -rf *
  1655  ../combined/configure --target=xscale-elf --disable-nls --with- 
newlib --prefix=/usr/local/gcc-xscale-elf --disable-newlib-supplied- 
syscalls
  1656  make


Does the order look good to you?

Thanks!

-- 
Rick

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

Brian, Tim, Ted: Thank you for your help.

I seem to be building GCC now under Cygwin. However, it's going VERY  
slowly. The desktops we have here are generations behind my MacBook  
Pro, it appears.

This is really a newlib question, but traffic seems light on that list.

How can i get the combined build to not build multilib versions of  
newlib, but rather, just one version that matches the targeted  
processor?

Is it enough to specify

--disable-multilib

or must I do something in addition?

TIA,
Rick

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Brian Dessent]

Rick Mann wrote:

> I seem to be building GCC now under Cygwin. However, it's going VERY
> slowly. The desktops we have here are generations behind my MacBook
> Pro, it appears.

Cygwin imposes a sometimes significant performance penalty as a tradeoff
for being able to use POSIX apis on a system where they don't exist, so
this is expected.  Particularly, the fork/exec sequence that is at the
heart of POSIX process creation is extremely slow under Cygwin, and
shell scripts that spawn many subprocesses this way suffer the most.

> This is really a newlib question, but traffic seems light on that list.
> 
> How can i get the combined build to not build multilib versions of
> newlib, but rather, just one version that matches the targeted
> processor?
> 
> Is it enough to specify
> 
> --disable-multilib

That is always what I've used (at the toplevel configure) and it seems
to work fine.

Brian

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Ted Byers]

--- Rick Mann <rmann@latencyzero.com> wrote:

> Brian, Tim, Ted: Thank you for your help.
> 
> I seem to be building GCC now under Cygwin. However,
> it's going VERY  
> slowly. The desktops we have here are generations
> behind my MacBook  
> Pro, it appears.
> 
Define "VERY slowly."  On my system, I set it to build
in the evening, and it is complete about 12 hours
later.  I used the following to configure it:

../gcc-4.2.2/configure --srcdir=../gcc-4.2.2 --verbose
--disable-nls --without-included-gettext
--enable-version-specific-runtime-libs --without-x
--disable-libgcj --disable-libgcj-debug
--disable-java-awt --with-system-zlib
--enable-java-gc=boehm --enable-threads=posix
--enable-sjlj-exceptions --disable-win32-registry
--with-win32-nlsapi=unicode
--enable-hash-synchronization --enable-libstdcxx-debug
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang

NB: I am building support for all the languages.  I
have yet to see a build with this configuration fail a
significant number of tests in the test suite (I
always to make check before attempting an install.

Since you aren't building everything, IIRC, your build
ought to take less time.

Now, make check takes more time than the basic build,
so I leave off starting that until the weekend.

> This is really a newlib question, but traffic seems
> light on that list.
> 
> How can i get the combined build to not build
> multilib versions of  
> newlib, but rather, just one version that matches
> the targeted  
> processor?
> 
> Is it enough to specify
> 
> --disable-multilib
> 
> or must I do something in addition?
> 
Don't know. I haven't had to investigate that.  I just
thought I'd give you a little information about how
long my builds of GCC take, along with how I configure
it, to better put the time of your builds into
perspective.  My hardware was obsolete when I bought
it, as is normal: 3800+ AMD Athlon 64 X2, w/ 4 GB RAM
(Yes, I know, 32 bit Windows sees only 3.5 GB, but
hey, I'll eventually upgrade it to 64 bit Windows, and
might as well get the RAM while it is available and
affordable).   Just how long are your builds taking?

Ted

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Rick Mann]

On Dec 13, 2007, at 4:57 PM, Ted Byers wrote:

> Define "VERY slowly."  On my system, I set it to build
> in the evening, and it is complete about 12 hours

Thanks for the data point. I started my build at about noon, and it  
was still going 5 hours later. I don't know what kind of machine it  
is; some Dell desktop. Hearing that it takes you 12 hours at least  
lets me know I made the right decision going home early :-)

By contrast, my 2.13 GHz dual core (not core 2) MacBook Pro builds it  
in under 45 minutes.

I'm sure it's both the slow machine and the Cygwin overhead. I'll just  
let it keep running overnight. Hopefully it will build my target  
binary properly the first time out.

Thanks again!

-- 
Rick

Re: Should I be able to build cross gcc 4.x on Cygwin?

[Kai Ruottu]

Rick Mann wrote:
> How can i get the combined build to not build multilib versions of 
> newlib, but rather, just one version that matches the targeted processor?
The weirdest thing here is this "reinventing the wheel" !

I understood newlib already being built for the $target on MacOS X.  But 
for some very peculiar reason it should be reproduced for just
the same $target on Cygwin....

What will happen next ?

  o the results will be compared, file by file and if there is any 
difference, one of the produced GCCs outputs bad code... But which one?
     This can be a good test for the "equivalency" or "similarity" of 
the two GCCs on different hosts.

  o the results will NOT be compared, any differences are taken as "host 
dependencies", of course a Cygwin-hosted GCC produces
    different code for the $target than a MacOS X hosted one...  (Does 
someone really believe this?)

What will the up-to-date "software engineering" books say about this 
wheel-reinvention?  I read my "Pressman" ("A practitioner's approach")
over 10 years ago, so I don't remember any advices for reinventions in 
these things  :(

I myself would TRUST that newlib done on MacOS X and would keep ONLY 
that on both hosts.  If some day there would be some
bugs found, the MacOS X hosted GCC would be sued or the newlib 
sources.... Maybe then trying the Cygwin hosted GCC to produce
the same newlib sources would come in question.