[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
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
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.ti...@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.
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
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
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
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
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
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
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
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
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
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
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
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
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
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. v...@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
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
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=gccview=revrev=167137 Log: 2010-11-25 Joern Rennecke amyl...@spamcop.net Ralf Wildenhues ralf.wildenh...@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
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
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=gccview=revrev=167137 Log: 2010-11-25 Joern Rennecke amyl...@spamcop.net Ralf Wildenhues ralf.wildenh...@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
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 000 0a0d 002 $ echo -e '\r' |tr -d '\015'|od -x 000 000a 001 $ 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
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
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=500 --split-size=500
--split-size=
500 --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=500 --split-size=500
--split-size=
500 --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
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
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
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. [jo...@laria gcc]$ od -x tm.texi|head -5 000 6340 4320 706f 7279 6769 7468 2820 2943 020 3120 3839 2c38 3931 3938 312c 3939 2c32 040 3931 3339 312c 3939 2c34 3931 3539 312c 060 3939 2c36 3931 3739 312c 3939 2c38 3931 100 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: [amyl...@meolyon ~]$ echo -e '\r' |od -x 000 0a0d 002 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: [amyl...@meolyon ~]$ echo -e '\r' |tr -d '\015'|od -x 000 000a 001 The case statement can also be tested separately: [amyl...@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
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
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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-10-05 08:33:23 UTC --- The rule was added here: http://gcc.gnu.org/viewcvs?view=revisionrevision=161547
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
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
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
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.
