[Bug bootstrap/45888] New: tm.texi generation is not portable, rule is broken

[Bug bootstrap/45888] New: tm.texi generation is not portable, rule is broken

[rwild at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

           Summary: tm.texi generation is not portable, rule is broken
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rwild@gcc.gnu.org


The thread starting at:
<http://gcc.gnu.org/ml/gcc/2010-10/msg00020.html>
lists a number of issues around tm.texi:

The output produced by genhooks is not portable (newline encoding), so it
should either produce binary output, or diff should be used to compare for
changes.

The tm.texi rule is broken because it references non-existing
$(srcdir)/doc/target.def.  Also, it seems references to source and build tree
are a bit messed up.  The logic to trigger a warning for updating the wrong
file could need a look-over, too.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu.org

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 2010-10-05 08:33:23 UTC ---
The rule was added here:
<http://gcc.gnu.org/viewcvs?view=revision&revision=161547>

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[fxcoudert at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.10.05 18:19:43
                 CC|                            |fxcoudert at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-10-05 23:39:37 UTC ---
(In reply to comment #0)
> The thread starting at:
> <http://gcc.gnu.org/ml/gcc/2010-10/msg00020.html>
> lists a number of issues around tm.texi:
> 
> The output produced by genhooks is not portable (newline encoding), so it
> should either produce binary output, or diff should be used to compare for
> changes.

Sigh.  What was supposed to give C programs more portability works against
us here.

Using diff to ignore line-end space change would not really be satisfactory,
because then you'd get gratuitous changes in the checked in tm.texi whenever
there is a change in the newline encoding in effect when autogenerating a
changed tm.texi.
Unless we make the copy step do newline translation, that is.
So, what is the lesser evil in maintainability and portability?
Generating binary output with unix-style newlines (as we generally have
in our repository), or compare ignoring newline style and translating
while copying?

If we go for translating copying, do we make autoconf fail if no suitable
tool is found?  Would that be specific to --enable-maintainer-mode?  Or do
we postpone the failure till the tool is actually needed?

> The tm.texi rule is broken because it references non-existing
> $(srcdir)/doc/target.def.

Mea culpa.  That should be just a plain $(srcdir)/taget.def .

>  Also, it seems references to source and build tree
> are a bit messed up.  The logic to trigger a warning for updating the wrong
> file could need a look-over, too.

I've found a problem with a circular dependency, but the patch for that didn't
get reviewed:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html

If references to source / build trees are 'messed up' in other ways too,
could you please be a bit more specific?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-05 23:59:16 UTC ---
[resending manually to gcc-bugzilla while Bugzilla is broken and sending 
emails with a header From: address that bounces incoming comments]

On Tue, 5 Oct 2010, amylaar at gcc dot gnu.org wrote:

> I've found a problem with a circular dependency, but the patch for that didn't
> get reviewed:
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html

I don't see any patch pings.  The usual rules apply: ping an unreviewed 
patch about weekly, CC to relevant maintainers if necessary, until it is 
reviewed.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[rwild at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #4 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2010-10-07 04:57:28 UTC ---
> --- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-10-05 23:39:37 UTC ---
> > The output produced by genhooks is not portable (newline encoding), so it
> > should either produce binary output, or diff should be used to compare for
> > changes.
> 
> Sigh.  What was supposed to give C programs more portability works against
> us here.
> 
> Using diff to ignore line-end space change would not really be satisfactory,
> because then you'd get gratuitous changes in the checked in tm.texi whenever
> there is a change in the newline encoding in effect when autogenerating a
> changed tm.texi.

Good point.  Let's kill \r then.  It should be possible to use
  tr -d '\015'

on ASCII systems (\r is not portable to Solaris tr).  So for
portability you could pipe through this I guess:

case `echo X|tr X '\101'` in
 A) # ASCII based system
  tr -d '\015'
  ;;
 *) # EBCDIC based system
  tr -d '\r'
  ;;
esac

> Unless we make the copy step do newline translation, that is.
> So, what is the lesser evil in maintainability and portability?
> Generating binary output with unix-style newlines (as we generally have
> in our repository), or compare ignoring newline style and translating
> while copying?

> If we go for translating copying, do we make autoconf fail if no suitable
> tool is found?

There should always exist a suitable tool on systems where it is needed.
FWIW, I would just use the above in the Makefile though (after removing
the comments).

> I've found a problem with a circular dependency, but the patch for
> that didn't get reviewed:
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html

The hunk in that changing TEXI_GCCINT_FILES seems wrong, at least
gcc/doc/gccint.texi still has '@include tm.texi' so that's what the
dependency should be.

> If references to source / build trees are 'messed up' in other ways too,
> could you please be a bit more specific?

I think that should be it.  I was a bit confused when writing the
message.  Thanks.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-10-07 08:03:20 UTC ---
(In reply to comment #4)
> There should always exist a suitable tool on systems where it is needed.
> FWIW, I would just use the above in the Makefile though (after removing
> the comments).

Why would you remove the comments?

> The hunk in that changing TEXI_GCCINT_FILES seems wrong, at least
> gcc/doc/gccint.texi still has '@include tm.texi' so that's what the
> dependency should be.

It must depend on new-tm.texi, lest it gets not rebuilt when there is a
change in the source files.
You can't make tm.texi dependent on new-tm.texi, because that would again
create a circularity.
It think it would be OK to leave tm.texi in TEXI_GCCINT_FILES while adding
new-tm.texi, though I haven't tested this.  Also, there is not really any
point in leaving tm.texi there, because as far as make is concerned,
new-tm.texi
depends (indirectly) on tm.texi.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[Ralf.Wildenhues at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #6 from Ralf Wildenhues <Ralf.Wildenhues at gmx dot de> 2010-10-07 18:34:11 UTC ---
> (In reply to comment #4)
> > There should always exist a suitable tool on systems where it is needed.
> > FWIW, I would just use the above in the Makefile though (after removing
> > the comments).
> 
> Why would you remove the comments?

Because they won't work inside a makefile rule.

> > The hunk in that changing TEXI_GCCINT_FILES seems wrong, at least
> > gcc/doc/gccint.texi still has '@include tm.texi' so that's what the
> > dependency should be.
> 
> It must depend on new-tm.texi, lest it gets not rebuilt when there is a
> change in the source files.

Hmm, but since gccint.texi file includes tm.texi it still gets rebuilt
wrongly then.   Oh well, guess the real issue here is that interactive
things (requiring the user to do something) just can't be mapped well
to make syntax.  Not sure if we can do much about it.  Thanks.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #7 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-15 14:43:13 UTC ---
(In reply to comment #4)
> Good point.  Let's kill \r then.  It should be possible to use
>   tr -d '\015'

Do we still have to worry about old mac-style line ends, i.e. a sole \r?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #8 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-15 15:41:33 UTC ---
Created attachment 22400
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22400
Proposed patch

Does this patch work for you on Cygwin?

It doesn't address MacOS 9 Issues, but then, the current Makefile doesn't
do the right thing for MacOS 9 build systems either - assuming you can
actually configure GCC 4.6 on such a platform.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[rwild at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

Ralf Wildenhues <rwild at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anhvofrcaus at gmail dot
                   |                            |com

--- Comment #9 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2010-11-19 15:50:33 UTC ---
*** Bug 46549 has been marked as a duplicate of this bug. ***

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #10 from Anh Vo <anhvofrcaus at gmail dot com> 2010-11-20 00:05:19 UTC ---
(In reply to comment #8)
> Created attachment 22400 [details]
> Proposed patch
> Does this patch work for you on Cygwin?
> It doesn't address MacOS 9 Issues, but then, the current Makefile doesn't
> do the right thing for MacOS 9 build systems either - assuming you can
> actually configure GCC 4.6 on such a platform.

I have the results for this question. I hope you do not mind.

No, it did not work on Cygwin nor MinGW with error message below.

...
echo "@set BUGURL @uref{http://gcc.gnu.org/bugs.html}" >> gcc-vers.texiT; \
        mv -f gcc-vers.texiT gcc-vers.texi
if [ xinfo = xinfo ]; then \
                makeinfo --split-size=5000000 --split-size=5000000
--split-size=
5000000 --no-split -I . -I ../../gcc-4.6-20101113/gcc/doc \
                        -I ../../gcc-4.6-20101113/gcc/doc/include -o
doc/cpp.inf
o ../../gcc-4.6-20101113/gcc/doc/cpp.texi; \
        fi
if [ xinfo = xinfo ]; then \
                makeinfo --split-size=5000000 --split-size=5000000
--split-size=
5000000 --no-split -I . -I ../../gcc-4.6-20101113/gcc/doc \
                        -I ../../gcc-4.6-20101113/gcc/doc/include -o
doc/gcc.inf
o ../../gcc-4.6-20101113/gcc/doc/gcc.texi; \
        fi
make[3]: Circular s-tm-texi <- ../../gcc-4.6-20101113/gcc/doc/tm.texi
dependency
 dropped.
build/genhooks.exe \
                        ../../gcc-4.6-20101113/gcc/doc/tm.texi.in > tmp-tm.texi
case `echo X|tr X '\101'` in \
          A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
          *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
        esac
mv tmp2-tm.texi tmp-tm.texi
/bin/sh ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi

You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
../../gcc-
4.6-20101113/gcc/doc/tm.texi .
make[3]: *** [s-tm-texi] Error 1
make[3]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x'
make: *** [all] Error 2

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #11 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-20 00:16:07 UTC ---
(In reply to comment #10)

> case `echo X|tr X '\101'` in \
>           A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
>           *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
>         esac
> mv tmp2-tm.texi tmp-tm.texi
> /bin/sh ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi
> 
> You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
> ../../gcc-
> 4.6-20101113/gcc/doc/tm.texi .

Does the generated tm.texi still have carriage return characters?
Or is there some other difference to the tm.texi in $(srcdir)/doc ?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #12 from Anh Vo <anhvofrcaus at gmail dot com> 2010-11-20 01:04:59 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > case `echo X|tr X '\101'` in \
> >           A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
> >           *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
> >         esac
> > mv tmp2-tm.texi tmp-tm.texi
> > /bin/sh ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi
> > 
> > You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
> > ../../gcc-
> > 4.6-20101113/gcc/doc/tm.texi .
> Does the generated tm.texi still have carriage return characters?
> Or is there some other difference to the tm.texi in $(srcdir)/doc ?

When opening tm.texi under Word, I see ¶ character at the end of the lines. It
must be the carriage return.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #13 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-20 01:31:12 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > Does the generated tm.texi still have carriage return characters?
> > Or is there some other difference to the tm.texi in $(srcdir)/doc ?
> 
> When opening tm.texi under Word, I see ¶ character at the end of the lines. It
> must be the carriage return.

I'm not sure - it's been ages since I had to use minicom on DOS for the lack
of a terminal program on Linux (There's been seyon since... ISPs... and ADSL.)

Do you have od installed under cygwin?
You could try
od -x tm.texi|less
to fine out what really is in there.  Or you could use hexdump if you have
that, but not od.

[joern@laria gcc]$ od -x tm.texi|head -5
0000000 6340 4320 706f 7279 6769 7468 2820 2943
0000020 3120 3839 2c38 3931 3938 312c 3939 2c32
0000040 3931 3339 312c 3939 2c34 3931 3539 312c
0000060 3939 2c36 3931 3739 312c 3939 2c38 3931
0000100 3939 322c 3030 2c30 3032 3130 0a2c 6340

Notice the penultimate byte pair in the last line above.  0a is newline.
carriage return would show up as 0d .

Assuming you actually have a carriage return there, I wonder where things
go wrong with the conversion.
On a Linux system, echo will not emit a carriage return by default, but
I can ask it to:

[amylaar@meolyon ~]$ echo -e '\r' |od -x
0000000 0a0d
0000002

You should be getting two carriage returns (0d) on cygwin with that command.

And then I can filter out the carriage return with the tr command used in
the makefile:

[amylaar@meolyon ~]$ echo -e '\r' |tr -d '\015'|od -x
0000000 000a
0000001

The case statement can also be tested separately:
[amylaar@meolyon ~]$ case `echo X|tr X '\101'` in \
>            A) echo ascii;;\
>            *) echo ebdic;;\
>          esac
ascii

Could you cut & paste this into a bash shell under cygwin and report the
results?

echo -e '\r' |od -x

echo -e '\r' |tr -d '\015'|od -x

case `echo X|tr X '\101'` in \
           A) echo ascii;;\
           *) echo ebdic;;\
         esac

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[cestrauss at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #14 from Cesar Strauss <cestrauss at gmail dot com> 2010-11-24 00:00:00 UTC ---
(In reply to comment #8)
> Created attachment 22400 [details]
> Proposed patch
> 
> Does this patch work for you on Cygwin?
> 

Dear Jorn,

I tried your patch on MinGW, and it does solve the issue for me. The tm.texi
file does not have CR anymore, allowing the build to proceed normally past this
point.

On Cygwin, the patch is not needed (but does no harm) because the default line
end encoding on Cygwin is already LF. So, in the patch, I suggest replacing the
comment "To make this work on Cygwin, remove \r." by "To make this work on
MinGW, remove \r.".

I do not know why your patch didn't work for Anh Vo, maybe the build directory
was not clean from a previous build. In any case, the tests you asked for do
run normally for me on both MinGW and Cygwin:

$ echo -e '\r' |od -x
0000000 0a0d
0000002

$ echo -e '\r' |tr -d '\015'|od -x
0000000 000a
0000001

$ case `echo X|tr X '\101'` in \
>            A) echo ascii;;\
>            *) echo ebdic;;\
>          esac
ascii

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #15 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-11-25 08:02:28 UTC ---
Author: amylaar
Date: Thu Nov 25 08:02:13 2010
New Revision: 167137

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167137
Log:
2010-11-25  Joern Rennecke  <amylaar@spamcop.net>
        Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

    PR bootstrap/45888
    * Makefile.in (s-tm-texi): Remove \r occurences from tmp-tm.texi.
    Fix target.def pathname in timestamp comparison.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #16 from Anh Vo <anhvofrcaus at gmail dot com> 2010-11-30 00:25:26 UTC ---
(In reply to comment #15)
> Author: amylaar
> Date: Thu Nov 25 08:02:13 2010
> New Revision: 167137
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167137
> Log:
> 2010-11-25  Joern Rennecke  <amylaar@spamcop.net>
>         Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
>     PR bootstrap/45888
>     * Makefile.in (s-tm-texi): Remove \r occurences from tmp-tm.texi.
>     Fix target.def pathname in timestamp comparison.
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/Makefile.in

I was on vacation last week. So, I did not have a chance to reply.

It is interesting that this fix worked for Cesar but not for me. In fact, it
failed the same way, as reported earlier, on both MinGW and Cygwin. Note that I
started out with a clean slate for these builds. The respective result from
uname -a comnand for MinGW and Cygwin are shown below.

$ uname -a
MINGW32_NT-5.1 GLDLCASC024623 1.0.11(0.46/3/2) 2009-07-11 17:46 i686 Msys

$ uname -a
CYGWIN_NT-5.1 GLDLCASC024623 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin

Anh Vo

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[Ralf.Wildenhues at gmx dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #17 from Ralf Wildenhues <Ralf.Wildenhues at gmx dot de> 2010-11-30 06:18:58 UTC ---
* anhvofrcaus at gmail dot com wrote on Tue, Nov 30, 2010 at 01:25:49AM CET:
> It is interesting that this fix worked for Cesar but not for me. In fact, it
> failed the same way, as reported earlier, on both MinGW and Cygwin.

Can you show 'cd gcc && make SHELL="/bin/sh -x"' output?
With Cygwin, are you on a text or binmode mount?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #18 from Anh Vo <anhvofrcaus at gmail dot com> 2010-11-30 17:00:31 UTC ---
(In reply to comment #17)
> * anhvofrcaus at gmail dot com wrote on Tue, Nov 30, 2010 at 01:25:49AM CET:
> > It is interesting that this fix worked for Cesar but not for me. In fact, it
> > failed the same way, as reported earlier, on both MinGW and Cygwin.
> Can you show 'cd gcc && make SHELL="/bin/sh -x"' output?
> With Cygwin, are you on a text or binmode mount?

The output below is shown below. It must be in text mode.

voax@GLDLCASC024623 /cygdrive/c/Gcc/Build-4.6.x
$ cd gcc && make SHELL="/bin/sh -x"
+ pwd
+ '[' -f /cygdrive/c/Gcc/Build-4.6.x/gcc/../binutils/ar ']'
+ '[' i686-pc-cygwin = i686-pc-cygwin ']'
+ echo ar
+ '[' -f /cygdrive/c/Gcc/Build-4.6.x/gcc/../binutils/ranlib ']'
+ '[' i686-pc-cygwin = i686-pc-cygwin ']'
+ echo ranlib
+ '[' -f /cygdrive/c/Gcc/Build-4.6.x/gcc/../binutils/strip ']'
+ '[' i686-pc-cygwin = i686-pc-cygwin ']'
+ echo strip
+ echo /usr/local/lib
+ sed -e 's|^/usr/local||' -e 's|/$||' -e 's|^[^/]|/|' -e 's|/[^/]*|../|g'
+ echo /usr/local
+ sed -e 's|^/usr/local||' -e 's|^/||' -e '/./s|$|/|'
+ echo gcc
+ sed s,y,y,
+ echo gcc
+ sed s,y,y,
+ echo cpp
+ sed s,y,y,
+ echo gcov
+ sed s,y,y,
+ cat ../../gcc-4.6-20101113/gcc/BASE-VER
+ cat ../../gcc-4.6-20101113/gcc/DEV-PHASE
+ cat ../../gcc-4.6-20101113/gcc/DATESTAMP
+ echo c++
+ sed s,y,y,
+ echo g++
+ sed s,y,y,
+ echo c++
+ sed s,y,y,
+ echo g++
+ sed s,y,y,
+ echo gfortran
+ sed s,y,y,
+ echo gfortran
+ sed s,y,y,
+ echo gcj
+ sed s,y,y,
+ echo gcj
+ sed s,y,y,
+ echo gt-coverage.h gt-caller-save.h gt-alias.h gt-bitmap.h gt-cselib.h
gt-cgra
ph.h gt-ipa-prop.h gt-ipa-cp.h gt-ipa-inline.h gt-matrix-reorg.h gt-dbxout.h
gt-
ipa-struct-reorg.h gt-dwarf2out.h gt-dwarf2asm.h gt-tree-vect-generic.h
gt-dojum
p.h gt-emit-rtl.h gt-explow.h gt-expr.h gt-function.h gt-except.h gt-gcse.h
gt-i
ntegrate.h gt-lists.h gt-optabs.h gt-profile.h gt-mcf.h gt-reg-stack.h
gt-cfglay
out.h gt-sdbout.h gt-stor-layout.h gt-stringpool.h gt-tree.h gt-varasm.h
gt-gimp
le.h gt-tree-mudflap.h gt-tree-ssanames.h gt-tree-eh.h gt-tree-ssa-address.h
gt-
tree-cfg.h gt-tree-dfa.h gt-tree-iterator.h gt-gimplify.h
gt-tree-scalar-evoluti
on.h gt-tree-profile.h gt-tree-nested.h gt-varpool.h gt-tree-parloops.h
gt-omp-l
ow.h gt-targhooks.h gt-config/i386/i386.h gt-passes.h gt-cgraphunit.h
gt-tree-ss
a-propagate.h gt-tree-phinodes.h gt-tree-ssa-structalias.h gt-lto-symtab.h
gt-co
nfig/i386/winnt.h gt-ada/gcc-interface/decl.h gt-ada/gcc-interface/trans.h
gt-ad
a/gcc-interface/utils.h gt-ada/gcc-interface/misc.h gt-cp/rtti.h gt-cp/mangle.h
gt-cp/name-lookup.h gt-cp/call.h gt-cp/decl.h gt-cp/decl2.h gt-cp/pt.h
gt-cp/rep
o.h gt-cp/semantics.h gt-cp/tree.h gt-cp/parser.h gt-cp/method.h
gt-cp/typeck2.h
 gt-c-family/c-common.h gt-c-family/c-lex.h gt-c-family/c-pragma.h
gt-cp/class.h
 gt-cp/cp-objcp-common.h gt-cp/cp-lang.h gt-fortran/f95-lang.h
gt-fortran/trans-
decl.h gt-fortran/trans-intrinsic.h gt-fortran/trans-io.h
gt-fortran/trans-stmt.
h gt-fortran/trans-types.h gt-java/builtins.h gt-java/class.h
gt-java/constants.
h gt-java/decl.h gt-java/expr.h gt-java/jcf-parse.h gt-java/lang.h
gt-java/mangl
e.h gt-java/resource.h gt-lto/lto-lang.h gt-lto/lto.h gt-c-parser.h gt-c-decl.h
gt-c-objc-common.h gt-c-family/c-common.h gt-c-family/c-pragma.h
gt-objc/objc-ac
t.h gt-objcp/objcp-decl.h gt-objc/objc-act.h gt-cp/rtti.h gt-cp/mangle.h
gt-cp/n
ame-lookup.h gt-cp/call.h gt-cp/decl.h gt-cp/decl2.h gt-cp/pt.h gt-cp/repo.h
gt-
cp/semantics.h gt-cp/tree.h gt-cp/parser.h gt-cp/method.h gt-cp/typeck2.h
gt-c-f
amily/c-common.h gt-c-family/c-lex.h gt-c-family/c-pragma.h
gt-cp/cp-objcp-commo
n.h gt-c-lang.h gt-c-decl.h gt-c-family/c-common.h gt-c-family/c-cppbuiltin.h
gt
-c-family/c-pragma.h gt-c-objc-common.h gt-c-parser.h
+ sed -e 's|/[^ ]*/|/|g' -e 's|gt-config/|gt-|g'
+ true
[repeating]
+ true
build/genhooks.exe \
                        ../../gcc-4.6-20101113/gcc/doc/tm.texi.in > tmp-tm.texi
+ build/genhooks.exe ../../gcc-4.6-20101113/gcc/doc/tm.texi.in
case `echo X|tr X '\101'` in \
          A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \
          *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \
        esac
+ case `echo X|tr X '\101'` in
++ echo X
++ tr X '\101'
+ tr -d '\015'
mv tmp2-tm.texi tmp-tm.texi
+ mv tmp2-tm.texi tmp-tm.texi
/bin/sh -x ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi
+ /bin/sh -x ../../gcc-4.6-20101113/gcc/../move-if-change tmp-tm.texi tm.texi
+ usage='../../gcc-4.6-20101113/gcc/../move-if-change: usage:
../../gcc-4.6-2010
1113/gcc/../move-if-change SOURCE DEST'
+ case $# in
+ for arg in '"$1"' '"$2"'
+ case $arg in
+ for arg in '"$1"' '"$2"'
+ case $arg in
+ test -r tm.texi
+ cmp -s tmp-tm.texi tm.texi
+ rm -f tmp-tm.texi
+ cmp -s ../../gcc-4.6-20101113/gcc/doc/tm.texi tm.texi
+ test ../../gcc-4.6-20101113/gcc/doc/tm.texi -nt
../../gcc-4.6-20101113/gcc/doc
/tm.texi.in
+ test ../../gcc-4.6-20101113/gcc/doc/tm.texi -nt
../../gcc-4.6-20101113/gcc/tar
get.def
+ echo

+ echo You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
../
../gcc-4.6-20101113/gcc/doc/tm.texi .
You should edit ../../gcc-4.6-20101113/gcc/doc/tm.texi.in rather than
../../gcc-
4.6-20101113/gcc/doc/tm.texi .
+ false
make: *** [s-tm-texi] Error 1

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[cestrauss at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #19 from Cesar Strauss <cestrauss at gmail dot com> 2010-12-02 23:38:39 UTC ---
(In reply to comment #18)
> (In reply to comment #17)
> > * anhvofrcaus at gmail dot com wrote on Tue, Nov 30, 2010 at 01:25:49AM CET:
> > > It is interesting that this fix worked for Cesar but not for me. In fact, it
> > > failed the same way, as reported earlier, on both MinGW and Cygwin.

Dear Anh Vo,

Please install the "file" utility. It should be able to identify if a file has
CR or CRLF line terminators.

Then, run in the source directory:

file gcc/doc/tm.texi

And in the build directory:

file gcc/tm.texi

Another way is to open the files using notepad. If the lines run all together,
then the file has LF line terminators. If the lines look normal, then it has
CRLF line terminators.

Thanks,
Cesar

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #20 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-03 00:46:12 UTC ---
(In reply to comment #19)

> Please install the "file" utility. It should be able to identify if a file has
> CR or CRLF line terminators.

With od, we can see exactly, byte for byte, where they are.  Or any other
differences, for that matter.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #21 from Anh Vo <anhvofrcaus at gmail dot com> 2010-12-03 17:45:58 UTC ---
Executing command 'file gcc/doc/tm.texi' yields
../gcc-4.6-20101113/gcc/doc/tm.texi: ASCII English text, with CRLF line
terminators. 

However, executing command 'file gcc/tm.texi' in the build directory outputs
gcc/tm.texi: ASCII English text, with very long lines.

Obviously, the results are not the same.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #22 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-03 17:57:22 UTC ---
(In reply to comment #21)
> Executing command 'file gcc/doc/tm.texi' yields
> ../gcc-4.6-20101113/gcc/doc/tm.texi: ASCII English text, with CRLF line
> terminators. 

So, does your source come from untarring a snapshot?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #23 from Anh Vo <anhvofrcaus at gmail dot com> 2010-12-03 18:08:27 UTC ---
Yes, it is. In fact, I downloaded it from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/. The exact name of the
snapshot is gcc-4.6-20101113.tar.bz2.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |REOPENED

--- Comment #24 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-03 18:15:18 UTC ---
(In reply to comment #23)
> Yes, it is. In fact, I downloaded it from
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/. The exact name of the
> snapshot is gcc-4.6-20101113.tar.bz2.

So the problem is that when building from an untarred snapshot / release,
CRLF translation might have been applied - unlike with svn, where you see
wxactly what is in the repository.

I suppose we should make a copy of $(srcdir)/doc/tm.texi with \r removed as
well, so that the comparison can succeed no matter if \r has been inserted or
not.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #25 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-03 21:35:52 UTC ---
Created attachment 22624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22624
patch to use \r-stripped copy of $(srcdir)/doc/tm.texi for comparison

Could you verify if this patch helps for your setting?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #26 from Anh Vo <anhvofrcaus at gmail dot com> 2010-12-03 22:35:13 UTC ---
Rebuilding was just started.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #27 from Anh Vo <anhvofrcaus at gmail dot com> 2010-12-03 23:23:49 UTC ---
No, the build still failed the same way. In fact, when issuing command 'file
gcc/tm.texi' on the build directory, gcc/tm.texi: ASCII English text, with very
long lines is outputed.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #28 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-04 01:03:18 UTC ---
(In reply to comment #27)
> No, the build still failed the same way. In fact, when issuing command 'file
> gcc/tm.texi' on the build directory, gcc/tm.texi: ASCII English text, with very
> long lines is outputed.

Did your Makefile actually get regenerated?

The idea is that gcc/tm.texi is no longer compared against
$(srcdir))/doc/tm.texi,
but against gcc/tmp3-tm.texi, which should have the same line endings as
gcc/tm.texi .

This temporary file is not deleted in the miscompare case, so you should be
able to inspect it, too.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #29 from Anh Vo <anhvofrcaus at gmail dot com> 2010-12-07 17:13:08 UTC ---
(In reply to comment #28)
> (In reply to comment #27)
> > No, the build still failed the same way. In fact, when issuing command 'file
> > gcc/tm.texi' on the build directory, gcc/tm.texi: ASCII English text, with very
> > long lines is outputed.
> Did your Makefile actually get regenerated?
> The idea is that gcc/tm.texi is no longer compared against
> $(srcdir))/doc/tm.texi,
> but against gcc/tmp3-tm.texi, which should have the same line endings as
> gcc/tm.texi .

gcc/tm.texi and gcc/tmp3-tm.texi did not have same same line ending. In fact,
gcc/tm.texi contains 'ASCII English text, with very long lines' while
gcc/tmp3-tm.texi has 'ASCII English text' only when examined with 'file'
command. In addition, gcc/tm.texi is slightly larger in size (507 KB) than
gcc/tmp3-tm.texi (493 KB).

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #30 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-10 02:04:26 UTC ---
(In reply to comment #29)
> gcc/tm.texi and gcc/tmp3-tm.texi did not have same same line ending. In fact,
> gcc/tm.texi contains 'ASCII English text, with very long lines' while
> gcc/tmp3-tm.texi has 'ASCII English text' only when examined with 'file'
> command. In addition, gcc/tm.texi is slightly larger in size (507 KB) than
> gcc/tmp3-tm.texi (493 KB).

I don't understand this at all.  The \r removal works for gcc/tm.texi,
but not for gcc/tmp3-tm.texi?  And yet the latter is smaller?  Or does
the latter have no line endings at all because you somehow untarred the
source file with MacOs 9 style line endings?

What size is your $(srcdir)/doc/tm.texi ?
How many lines do the varyous tm.texi files have?  (wc should tell)
Could you show the start of these files with od, like shown in
comment 13?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

--- Comment #31 from Anh Vo <anhvofrcaus at gmail dot com> 2010-12-11 00:54:08 UTC ---
(In reply to comment #30)
> (In reply to comment #29)
> > gcc/tm.texi and gcc/tmp3-tm.texi did not have same same line ending. In fact,
> > gcc/tm.texi contains 'ASCII English text, with very long lines' while
> > gcc/tmp3-tm.texi has 'ASCII English text' only when examined with 'file'
> > command. In addition, gcc/tm.texi is slightly larger in size (507 KB) than
> > gcc/tmp3-tm.texi (493 KB).
> I don't understand this at all.  The \r removal works for gcc/tm.texi,
> but not for gcc/tmp3-tm.texi?  And yet the latter is smaller?  Or does
> the latter have no line endings at all because you somehow untarred the
> source file with MacOs 9 style line endings?
> What size is your $(srcdir)/doc/tm.texi ?
> How many lines do the varyous tm.texi files have?  (wc should tell)
> Could you show the start of these files with od, like shown in
> comment 13?

This problem does not occur in the latest snapshot, gcc-4.6-20101204. In fact,
the build passed this point successfully. However, other problem surfaces. With
Cygwin build, it complained assembly code as shown in error message below.

[...]
make[4]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x/i686-pc-cygwin/libgcc'
/cygdrive/c/Gcc/Build-4.6.x/./gcc/xgcc -B/cygdrive/c/Gcc/Build-4.6.x/./gcc/
-B/u
sr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/loca
l/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include    -g
-O
2 -O2 -I../../gcc-4.6-20101204/gcc/../winsup/w32api/include
-I../../gcc-4.6-2010
1204/gcc/../winsup/include
-I../../gcc-4.6-20101204/gcc/../winsup/cygwin/include
 -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmi
ssing-prototypes -Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-
D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector   -I. -I. -I../.././gcc
-I../../../
gcc-4.6-20101204/libgcc -I../../../gcc-4.6-20101204/libgcc/.
-I../../../gcc-4.6-
20101204/libgcc/../gcc -I../../../gcc-4.6-20101204/libgcc/../include
-I../../../
gcc-4.6-20101204/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS
-DUSE_EMUTLS -o _chkstk_s.o -MT _chkstk_s.o -MD -MP -MF _chkstk_s.dep -DSHARED
-
DL_chkstk -xassembler-with-cpp \
          -c ../../../gcc-4.6-20101204/libgcc/../gcc/config/i386/cygwin.asm
../../../gcc-4.6-20101204/libgcc/../gcc/config/i386/cygwin.asm: Assembler
messag
es:
../../../gcc-4.6-20101204/libgcc/../gcc/config/i386/cygwin.asm:30: Error:
unknow
n pseudo-op: `.cfi_sections'
make[3]: *** [_chkstk_s.o] Error 1
make[3]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x/i686-pc-cygwin/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/cygdrive/c/Gcc/Build-4.6.x'
make: *** [all] Error 2

For MinGW build, it complained about lto plugin as shown below.

[...]
make[3]: Entering directory `/c/Gcc/Build-Test/lto-plugin'
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../gcc-
4.6-20101204/lto-plugin  -I../../gcc-4.6-20101204/lto-plugin/../include
-DHAVE_C
ONFIG_H  -Wall -Werror -g -fkeep-inline-functions -c -o lto-plugin.lo
../../gcc-
4.6-20101204/lto-plugin/lto-plugin.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../gcc-4.6-20101204/lto-plugin
-
I../../gcc-4.6-20101204/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g
-
fkeep-inline-functions -c ../../gcc-4.6-20101204/lto-plugin/lto-plugin.c 
-DDLL_
EXPORT -DPIC -o .libs/lto-plugin.o
cc1.exe: warnings being treated as errors
../../gcc-4.6-20101204/lto-plugin/lto-plugin.c: In function 'exec_lto_wrapper':
../../gcc-4.6-20101204/lto-plugin/lto-plugin.c:556:3: error: implicit
declaratio
n of function 'WIFEXITED'
../../gcc-4.6-20101204/lto-plugin/lto-plugin.c:556:3: error: implicit
declaratio
n of function 'WEXITSTATUS'
make[3]: *** [lto-plugin.lo] Error 1
make[3]: Leaving directory `/c/Gcc/Build-Test/lto-plugin'
make[2]: *** [all-stage1-lto-plugin] Error 2
make[2]: Leaving directory `/c/Gcc/Build-Test'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/c/Gcc/Build-Test'
make: *** [all] Error 2

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #32 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2010-12-11 03:50:45 UTC ---
(In reply to comment #31)
> This problem does not occur in the latest snapshot, gcc-4.6-20101204. In fact,
> the build passed this point successfully.

Good.  I'm closing this PR now then.
As we have no details about what exactly happened with the previous
snapshot, my best guess is that something with applying the patch didn't
quite work right at your end, or the extracted snapshot was corrupted to
begin with.

> However, other problem surfaces. With
> Cygwin build, it complained assembly code as shown in error message below.

This is clearly a separate issue.  Please open a new PR for it, unless that
has already been done, and/or the problem has been fixed, in the meantime.

> For MinGW build, it complained about lto plugin as shown below.

That, too, is a separate issue.  You clearly seem to be unlucky with your
snapshots, as this has been fixed just after the snapshot was made:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00369.html

r167468 | ktietz | 2010-12-05 09:06:25 +0100 (Sun, 05 Dec 2010) | 9 lines

2010-12-05  Kai Tietz  <kai.tietz@onevision.com>

        * config.h.in: Regenerated.
        * configure: Regenerated.
        * configure.ac (AC_CHECK_HEADERS): Replaced by AC_HEADER_SYS_WAIT.
        * lto-plugin.c (WIFEXITED): Define default.
        (WEXITSTATUS): Likeiwse.