crosstool-ng: patches/gcc/3.2.3/README-sh@ea15433daba0

Ah! I finally have a progress bar that doesn't stall the build!
- pipe size in Linux is only 8*512=4096 bytes
- pipe size is not setable
- when the feeding process spits out data faster than the eating
process can read it, then the feeding process stalls after 4KiB
of data sent to the pipe
- for us, the progress bar would spawn a sub-shell every line,
and the sub-shell would in turn spawn a 'date' command.
Which was sloooww as hell, and would cause some kind of a
starvation: the pipe was full most of the time, and the
feeding process was stalled all this time.

Now, we use internal variables and a little hack based onan offset
to determine the elapsed time. Much faster this way, but still
CPU-intensive.

     1 http://mirror.sh-linux.org/rpm-2003/SRPMS/gcc-3.2.3-3.src.rpm contains the following patches:

     3 gcc-20030210-sh-linux-1.patch

     4 gcc-3.2.3-libffi-1.patch

     5 gcc-3.2.3-sh-linux-dwarf2-1.patch (*not* applied by the spec file, it's in there by accident)

     7 gcc-3.2.3-libffi-1.patch was needed just to build, I think.

     9 After that was applied, sh4 gcc seemed to compile fine, but c++ programs

    10 failed to execute because libstdc++.so.5 was built without version

    11 info.  This was caused directly by libstdc++-v3/configure setting

    12 SYMVER_MAP=config/linker-map.dummy because it sees that

    13 no libgcc_s.so was generated; configure says

    14   checking for shared libgcc... no.

    16 Applying gcc-20030210-sh-linux-1.patch in hopes it makes those problems go away.

author	"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
	Sun May 20 13:48:26 2007 +0000 (2007-05-20)
changeset 112	ea15433daba0
permissions	-rw-r--r--