Summary: | Empty lines before #!/bin/sh in startx | ||
---|---|---|---|
Product: | xorg | Reporter: | Leonid Isaev <lisaev> |
Component: | App/xinit | Assignee: | Xorg Project Team <xorg-team> |
Status: | CLOSED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Leonid Isaev
2013-09-16 21:08:45 UTC
The shebang is the first line in the source file, and in the output when I run it here. Perhaps you're using a cpp that's inserting extra blank lines? http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp To add to my previous post (sorry for forgetting this), the system is archlinux x86_64 with gcc 4.8.1. (In reply to comment #1) > The shebang is the first line in the source file, and in the output when I > run it here. Perhaps you're using a cpp that's inserting extra blank lines? > > http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp I see. Then it's an issue on the distro side -- I'll look closer at the cpp behavior. Thanks. I tested with Solaris cpp & gcc 4.7.3 on Solaris, so it could be a change between gcc 4.7 & 4.8. This also affects xmkmf and makedepend from imake. These projects use cpp to parse cpp files to shellscript. Looking at the makefiles, this line is used to generate xmkmf: /usr/bin/cpp -undef -traditional -DCONFIGDIRSPEC='"-I/usr/lib/X11/config"' < ./xmkmf.cpp | /usr/bin/sed -e /^\#/d | /usr/bin/sed -e s/XCOMM/\#/ > xmkmf Changing it to: /usr/bin/cpp -undef -traditional -DCONFIGDIRSPEC='"-I/usr/lib/X11/config"' ./xmkmf.cpp | /usr/bin/sed -e /^\#/d | /usr/bin/sed -e s/XCOMM/\#/ > xmkmf leads to desired behavior. When cpp 4.8.x reads from stdin, it adds this on top: # 1 "<stdin>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 17 "/usr/include/stdc-predef.h" 3 4 [lots of newlines] # 1 "<command-line>" 2 # 1 "<stdin>" Changing it to read from file changes it: # 1 "./xmkmf.cpp" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "./xmkmf.cpp" Submitted patch to xorg-devel for review: http://patchwork.freedesktop.org/patch/15784/ Please test to ensure this works for you too. Fix pushed to git master: http://cgit.freedesktop.org/xorg/app/xinit/commit/?id=463b85fcf51d8ff5886ebe1f3481e5cb4d603436 Fix published in xinit 1.3.4: http://lists.x.org/archives/xorg-announce/2014-September/002477.html FWIW, I just sort of ran into an odd offshoot of this: https://bugs.freedesktop.org/show_bug.cgi?id=107368 it seems that no-one on this bug or the review threads etc. talked about *why* this change 'fixed' the bug. From some research in #107368 , it seems to me that what's going on is, when passed input via stdin and without any -x parameter, cpp will assume it's C. When passed input as a file with a .cpp extension, cpp assumes it's C++. For some reason, when it's treating these files as C or assembler, cpp (perhaps only cpp in gcc 4.8+, which is why this suddenly appeared?) adds a bunch of blank lines at the top. When it's treating them as C++, it doesn't. You can play around with this for yourself by deleting 'startx', running 'make -n' to get the full cpp command that 'make' would run, then renaming the files and modifying the command. For instance, if I leave the input file as 'startx.cpp' but add '-xc' or '-xassembler' to the cpp command (which overrides the file extension-based language detection and just *tells* cpp to treat the file as C or assembler), I get the blank lines. And if I rename the input file to 'startx.foo' but add '-xc++' to the cpp command, I get the file without the blank lines. So it seems like the 'fix' here was really a sort of slightly odd workaround, and it'd be interesting to figure out why cpp in 4.8 adds these blank lines when treating the code as C whereas cpp in 4.7 perhaps didn't. I ran across this because the fact that the '.cpp' extension makes cpp treat these files as C++ effectively makes the build depend on gcc-c++, even though there's no C++ code in it at all... |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.