Are you sure that you are actually trying to compile 1.1.0? Complete libcwrapper removal happened with commit 861debbf8d64. grep the three for snprintf and you will see that xf86snprintf is no longer there.

Aganist which X version are you trying to build?
Please check if there is a line containing  HAVE_XF86_ANSIC_H  in config.h.
Also all occurances of the xf86.. versions of strdup and snprintf are gone from the code. If you do a grep for these and they show up still you are not building 1.1.0.

  Hi,

  AdamW just asked me in irc, but to add more details,
including xf86_ansic.h gives a lot of errors in the format:
--
In file included from /usr/include/xorg/opaque.h:48,
                 from /usr/include/xorg/windowstr.h:60,
                 from /usr/include/xorg/randrstr.h:42,
                 from rhd_randr.c:50:
/usr/include/setjmp.h:49: error: conflicting types for 'xf86jmp_buf'
/usr/include/xorg/xf86_libc.h:99: error: previous declaration of 'xf86jmp_buf' was here
/usr/include/setjmp.h:53: error: expected ')' before '==' token
/usr/include/setjmp.h:83: error: conflicting types for 'xf86longjmp'
/usr/include/xorg/xf86_ansic.h:292: error: previous declaration of 'xf86longjmp' was here
In file included from /usr/include/xorg/glyphstr.h:29,
                 from /usr/include/xorg/picturestr.h:28,
                 from /usr/include/xorg/randrstr.h:50,
                 from rhd_randr.c:50:
--

  You can blame me on that because of the inclusion of setjmp.h in Mandriva,
as it is included due to a Mandriva only patch.

  AdamW was just packaging radeonhd, so I am not touching this package :-)
  The symbols are available in current Mandriva X Server, but I believe
only the radeonhd driver showed this problem, and I did not clearly understand
the cause earlier.

  Since this is a Mandriva specific problem, I believe you can ignore it,
or alternatively, don't use xf86_ansic.h and, hopefully, the generated
binary will be "compatible" with future versions of X org server, or work
with both, up to 1.4 branch and also work with a server that someone may
build checking out xserver git master.

I'm going to reorder some header inclusions. This may help to remedy your problem.

Created attachment 13417 [details] [review]
Reorder header: don't include wrapper before XOrg headers.

This patch should fix (at least some of) the compile problems reported here. Please test and supply dump of build errors that still exist.

  Thanks, it compiles with no problems with the patch.

  There are basically only warnings about C++ style comments. example:
./AtomBios/includes/CD_Common_Types.h:43:5: warning: C++ style comments are not allowed in ISO C90

  The warning about type of bit field being a GCC extension is probably because it is a structure composed of unsigned short bit fields (sizeof should be 2):
./AtomBios/includes/atombios.h:305: warning: type of bit-field 'WS_SizeInBytes' is a GCC extension

  There are warning about unamed unions, apparently used only to address the same field using 2 different names:
./AtomBios/includes/atombios.h:467: warning: ISO C doesn't support unnamed structs/unions

  There is another warning about commas at end of enumeration, but these are on xorg included headers:
/usr/include/xorg/picture.h:119: warning: comma at end of enumerator list

  There are also these warnings:
./AtomBios/includes/CD_Common_Types.h:76: warning: ignoring #pragma warning 



  I did not have pciutils-devel installed in the computer I tested it, so, after installing it, to build rhd_conntest, I just did "./configure --prefix=/usr; make clean all" to retest, and the warning about unamed unions became in the format:
./AtomBios/includes/atombios.h:467: warning: declaration does not declare anything

Paolo, thanks for testing! I've commited the patch, now.

we are aware of the warnings in atombios.h and CD_CommonTypes.c. These files were supplied by ATI where they come from the AtomBIOS suite/ Catalyst driver sources. 
We did intentionally left them unchanged as they may be updated by ATI at any time but we encouraged ATI to fix them.
In fact they are the only thing that breaks backward compatibility to anything ealier than 6.9 as the gcc options used at that time were a lot more strict.

Also the X.Org header contain a lot of enumerations with a trailing comma. This doesn't seem to be considered broken as the number of such cases has increased recently (with X.Org head we see many more cases than with 7.3).
I agree with you that these should be fixed - however in these days having these commas seems to be a fanshion statement (as they would be rather easy to avoid).

The warnings regarding atombios.h differ for the atombios parser code as we compile this with -std=c99. This is why you are seeing 'declaration does not declare anything' instead of 'ISO C doesn't support unnamed structs/unions'.

Paolo, thanks a lot again!

(In reply to comment #7)
> Also the X.Org header contain a lot of enumerations with a trailing comma. This
> doesn't seem to be considered broken as the number of such cases has increased
> recently (with X.Org head we see many more cases than with 7.3).
> I agree with you that these should be fixed - however in these days having
> these commas seems to be a fanshion statement (as they would be rather easy to
> avoid).

It's not a fashion statement, just a desire to avoid pointless merge conflicts.

enum meh {
    blah,
    placeholder,
    stuff,
+   things,
};
will work (with fuzz one) with:
enum meh {
    blah,
    placeholder,
    stuff,
+   misc,
};
also applied.

However, it won't work if the comma is omitted, because you'll have:
-   stuff
+   stuff,
on both, which will fail for the second one.

  Thanks for the clarifications.

  I believe gcc is verbose about commas (when told to be so) because AFAIK
code like this may not compile with (very) old compilers. But this is
I believe, due to original/old ANSI C specification. Probably it used to be
flagged as an programming error, and classified as an empty expression or
something.