When building emacs using GCC greater than 4.4.2, the following error occurs: make -j3 CC=x86_64-pc-linux-gnu-gcc cd lib-src; make all - --jobserver-fds=3,4 -j \ CC='x86_64-pc-linux-gnu-gcc' CFLAGS='-march=athlon64 -pipe -O2' CPPFLAGS='-D_BSD_SOURCE ' \ LDFLAGS='-Wl,-O1 -Wl,-znocombreloc ' MAKE='make' make[1]: Entering directory `/var/tmp/portage/app-editors/emacs-23.1-r3/work/emacs-23.1/lib-src' Makefile:148: *** commands commence before first target. Stop. make[1]: Leaving directory `/var/tmp/portage/app-editors/emacs-23.1-r3/work/emacs-23.1/lib-src' make: *** [lib-src] Error 2 This error has apparently already been fixed upstream. It is related to a change in the way the C preprocessor handles escaped newlines. A patch for 23.1 can be found at the Red Hat bugzilla URL given above. I have confirmed that the patch solves the problem.
I cannot reproduce this (I've tried with both gcc 4.4.2 and gcc 4.4.3 on x86 and amd64). Please attach your build.log and "emerge --info" output.
Attach lib-src/Makefile too, please.
I've been using the GCC 4.5.0 SVN snapshot (from the toolchain overlay), and apparently I can no longer get 4.4.3 to work without rebuilding glibc, which I'm not really prepared to do, so I guess I can't confirm that this fails there. I was relying on the Fedora bug to give me correct GCC version info. Since GCC 4.5 is not officially supported by Gentoo, I suppose you could close this bug as WONTFIX, but it *will* come back to haunt us. The failure happens every time with GCC 4.5. In any case, I am attaching the three files you requested.
Created attachment 222991 [details] build.log
Created attachment 222993 [details] emerge --info output
Created attachment 222997 [details] lib-src/Makefile
What is the output of the testcase (from the Redhat bug): $ cpp --version $ echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | cpp $ echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | cpp -P
echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/cpp # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" obj= foo bar baz echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-pre9999/cpp # 1 "<stdin>" # 1 "<built-in>" # 1 "<command-line>" # 1 "<stdin>" obj= foo bar baz echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | /usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3/cpp -P obj= foo bar baz echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-pre9999/cpp -P obj= foo bar baz
$ cpp --version cpp (Gentoo SVN) 4.5.0-pre9999 20100304 (experimental) rev. 157225 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(In reply to comment #8) > echo -e 'obj= foo \\\n\tbar \\\n\tbaz\n' | > /usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-pre9999/cpp > # 1 "<stdin>" > # 1 "<built-in>" > # 1 "<command-line>" > # 1 "<stdin>" > obj= foo > bar > baz Unless I completely misunderstand the C99 standard, this is broken behaviour. For example, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf says in section 5.1.1.2 "Translation phases": | Each instance of a backslash character (\) immediately followed by a | new-line character is deleted, splicing physical source lines to form | logical source lines. Reassigning to gcc-porting.
(In reply to comment #10) > Reassigning to gcc-porting. Should rather be toolchain since it's a bug in GCC itself.
According to GCC's bugzilla, this is as designed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41748
gcc-porting bugs should be assigned to the maintainer of the package and block the appropriate gcc-porting tracker. this has been fixed upstream so it is a bug in the package. it's up to you if you want to patch it or wait for a new version to be released with this fix before 4.5 is added to the tree. please leave this bug open if you decide not to so we can track what needs to be done before 4.5 is added. in the meantime i'll add this patch to the gcc-porting overlay.
(In reply to comment #12) > According to GCC's bugzilla, this is as designed: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41748 I still think that it violates the standard, which explicitly says that backslash-newline is deleted. Anyway, adding the -P option shouldn't harm, so I've done this now. No revbump because it is a build-time issue. Could you please verify if all SLOTs (i.e. 18, 21, 22, 23) of app-editors/emacs build with GCC 4.5?
app-editors/emacs:18, app-editors/emacs:21 and app-editors/emacs:22 all build successfully for me with gcc 4.5.
as does 23, of course. Many thanks!
Thank you for testing, and for reporting the issue.
This also affects 23.1-r2, the current stable, -r3 build fine now.
yes, building stable packages with as-yet-unkeyworded compilers can never be expected to work.
