Bug 605588 - does not compile: connection.c:620: error: invalid initializer
Summary: does not compile: connection.c:620: error: invalid initializer
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 14
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 657437
TreeView+ depends on / blocked
 
Reported: 2010-06-18 10:42 UTC by Sami Farin
Modified: 2010-12-23 18:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 657437 (view as bug list)
Environment:
Last Closed: 2010-10-25 20:55:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Sami Farin 2010-06-18 10:42:21 UTC
Description of problem:
connection.c:620: error: invalid initializer

Version-Release number of selected component (if applicable):
1.8.0-7

How reproducible:
always

Steps to Reproduce:
1. build it
2.
3.
  
Actual results:
fail

Expected results:
success

Additional info:
make[1]: Entering directory `/usr/src/redhat/BUILD/xorg-server-1.8.0/os'
  CC     connection.lo
connection.c: In function 'NotifyParentProcess':
connection.c:362: warning: ignoring return value of 'write', declared with attribute warn_unused_result
connection.c: In function 'AuthAudit':
connection.c:620: error: invalid initializer
make[1]: *** [connection.lo] Error 1

in the .i file
    XSERVER_CLIENT_AUTH(client->index, addr, client_pid, client_zid);
morphs into:

    do if (__builtin_expect ( client__auth_semaphore , 0)) { volatile __typeof__(((client->index))) arg1 = (client->index); volatile __typeof__(((addr))) arg2 = (addr); volatile __typeof__(((client_pid))) arg3 = (client_pid); volatile __typeof__(((client_zid))) arg4 = (client_zid); ; __asm__ volatile (".section .probes," "\"aw\"" "\n" "\t.balign 8\n" "1:\n\t.asciz " "\"client__auth\"" "\n" "\t.balign 4\n" "\t.int " "0x31425250" "\n" "\t.balign 8\n" "\t.quad " "1b\n" "\t.balign 8\n" "\t.quad " "2f" "\n" "\t.int 0\n" "\t.previous\n"); __asm__ volatile ("2:\n" "\tnop " "/* %0 %1 %2 %3 */" :: "g"(arg1), "g"(arg2), "g"(arg3), "g"(arg4)); } while (0);

Comment 1 Bug Zapper 2010-07-30 12:09:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 Adam Jackson 2010-08-02 21:53:31 UTC
I suspect you have systemtap-sdt-devel installed.  Don't do that.

But we should probably fix the specfile to explicitly turn dtrace support off.

Comment 3 Adam Jackson 2010-10-25 20:55:15 UTC
Fixed in rawhide.

Comment 4 Boris B. Zhmurov 2010-11-24 21:27:56 UTC
Adam, can you, please, fix it for RHEL6 too? The same issue occures, when I rebuild xorg-x11-server-1.7.7-26.el6.src.rpm on RHEL6 box.

Thanks

Comment 5 Frank Ch. Eigler 2010-11-26 02:35:42 UTC
"I suspect you have systemtap-sdt-devel installed.  Don't do that."

A more useful response would have been to involve the systemtap team in fixing whatever build problems arise.  I'll clone this bug to that effect.

Comment 6 Nicolas PENINGUY 2010-12-23 17:43:07 UTC
For the record, xorg-x11-server >= 1.9.3 should compile with systemtap-sdt-devel installed (tested on Fedora 14). I encountered a build issue (different errors than yours however) and submitted a fix to Xserver. See http://cgit.freedesktop.org/xorg/xserver/commit/?id=311cad33155c64ed996418808727fc417168592e

However if you try to build the RPM with DTrace enabled you'll still get this error:

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/share/doc/xorg-server/Xserver-DTrace.html
   /usr/share/doc/xorg-server/Xserver-DTrace.pdf

As Systemtap support is quite useless without a proper tapset file, I think it's a good thing to explicitly turn dtrace support off.

Comment 7 Frank Ch. Eigler 2010-12-23 17:58:38 UTC
"As Systemtap support is quite useless without a proper tapset file,"

Why do you think so?  Basic stuff like tracing everything:
# stap -e 'probe process("/usr/bin/Xorg").mark("*") { log($$parms) }'
should work.

Comment 8 Nicolas PENINGUY 2010-12-23 18:10:07 UTC
You're right, it works, I tested it some time ago. I should have said it's not as user friendly as with a tapset instead.


Note You need to log in before you can comment on or make changes to this bug.