Bug 21827

Summary: faulty sdksyms.c generated by the awk script in sdksyms.sh
Product: xorg Reporter: Korey Lu <koreylu>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: alainsergenagni, bryanh
Version: gitKeywords: patch
Hardware: All   
OS: Linux (All)   
i915 platform: i915 features:
Description Flags
This patch fixes it for me. none

Description Korey Lu 2009-05-20 03:16:55 UTC
Met this issue when I was cross compiling the git version of xserver with GCC 3.4.6.

E.g.1, prototype in include/os.h is:

  extern _X_EXPORT void OsBlockSignals (void); // there is an extra blank space

Expected result in sdksyms.c is:

  (void *) &OsBlockSignals,

Actual result in sdksyms.c is:

  (void *) &void,

E.g.2, prototype in include/input.h is:

  extern _X_EXPORT int GetEventList(EventListPtr* list); // not blank but a '*'

Expected result in sdksyms.c is:

  (void *) &GetEventList,

Actual result in sdksyms.c:

  (void *) &list,

This is because of the CPP I used, which ignores the `_X_EXPORT' directly.

arm-linux-cpp (GCC) 3.4.6
Reading specs from /opt/crosstool/gcc-3.4.6-glibc-2.3.6/arm-linux/lib/gcc/arm-linux/3.4.6/specs
Configured with: /home/bztu/crosstool-0.43/build/arm-linux/gcc-3.4.6-glibc-2.3.6/gcc-3.4.6/configure --target=arm-linux --host=i686-host_pc-linux-gnu --prefix=/opt/crosstool/gcc-3.4.6-glibc-2.3.6/arm-linux --with-cpu=arm9tdmi --enable-cxx-flags=-mcpu=arm9tdmi --with-headers=/opt/crosstool/gcc-3.4.6-glibc-2.3.6/arm-linux/arm-linux/include --with-local-prefix=/opt/crosstool/gcc-3.4.6-glibc-2.3.6/arm-linux/arm-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long

After preprocessing, the prototypes are:

  extern void OsBlockSignals (void); // e.g.1
  extern int GetEventList(EventListPtr* list); // e.g.2

And in the awk script in sdksyms.sh, n = 3, e.g.1 matches 

  if ($n !~ /[^a-zA-Z0-9_]/)

and e.g.2 matches

  $n ~ /\*$/

therefore we have n++ in each case, then get unexpected result as above.
Comment 1 Jesse Adkins 2010-10-22 15:22:55 UTC
*** Bug 23779 has been marked as a duplicate of this bug. ***
Comment 2 Jesse Adkins 2010-10-22 18:02:48 UTC
Confirming that this bug still exists in the current git. It's sdksyms.sh that's at fault, as I suspected.

This can be triggered by a simple jhbuild by editing Xfuncproto.h like so...

#if defined(__GNUC__) && (__GNUC__ >= 4) && !defined(__CYGWIN__)
# define _X_EXPORT      //__attribute__((visibility("default")))
# define _X_HIDDEN      //__attribute__((visibility("hidden")))
# define _X_INTERNAL    //__attribute__((visibility("internal")))

After doing so, trying to just 'Make' will result in the sorts of definitions that the reporter complained about.

The problem seems to be around 

	# type specifier may not be set, as in
	#   extern _X_EXPORT unsigned name(...)
	if ($n !~ /[^a-zA-Z0-9_]/) {

where something like extern _X_EXPORT void OsBlockSignals (void);

will have n at OsBlockSignals before the above snippet. After the n++, n becomes (void), resulting in &void being shown.
Comment 3 David Barksdale 2010-10-29 17:26:58 UTC
Created attachment 39892 [details] [review]
This patch fixes it for me.

I ran into this problem cross-compiling xorg-server-1.7.1 with gcc-3.4.5. This patch fixes it for me.
Comment 4 Bryan Henderson 2010-12-10 15:56:19 UTC
I too encountered this.  Lost an hour and a multi-day delay.

David's patch works for me.
Comment 5 Alan Coopersmith 2010-12-13 20:14:16 UTC
Fixes my Solaris builds with gcc 3.4.3 too.   (I normally build with
Sun Studio CC, which worked with the old script, but occassionally
try gcc for the different set of warnings reported.)

Submitted the patch to xorg-devel to get it into the review queue so
it gets applied instead of just leaving it to rot in bugzilla.

Comment 6 Alan Coopersmith 2010-12-20 09:04:13 UTC
Pulled into git master now for 1.10:
Comment 7 slackguy 2014-11-29 17:05:13 UTC
sdksyms.sh (orig) will not get all extern functions and also has an XV bug.  this new one i believe gets all.  see patch:


the old one tries to parse cpp output without bison, even though that's not as hard as parsing C, it is far trickier than the author thinks.  still not perfect is a rule the new one uses to decide what symb is good.  it's better i'd hate to say it's correct - i'm unsure. yet it leaves the casual make user in a much better position.

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.