Yeah, CONFIG_ENV_cc versus CONFIG_ENV_gcc But what I actually meant was more than that: First I had to simply switch on your predefined cc vs. gcc selector on sparc (your whole framework is, by the way, well designed, is totally self-explanatory and can easily be extended into any desired direction, with only minimum effort required). However, secondly I needed to add that cc_vs._gcc logic to some of my own diffs (which I hadn't done properly, at first / i.e. where I patch Makefile.am/Makefile.in's, i.e. in the bus subdir)
Besides that, a gcc build failed 4 times on sparc, with your patched sources. But - as I now know - due to my own fault: I had ./xorg-server-1.2.0/xkb/maprules.c include /usr/openwin/share/include/X11/extensions/XKBrules.h, rather than /usr/X11/include/X11/extensions/XKBrules.h. Why did I perform the whole SUNWspro vs. gcc testing? Well, I first wanted to be 100% sure, that Studio is indeed not an option for the hardware specific code, before finally moving over back to gcc. I had been hoping we could somehow get it going with Sun's cc, _reliably_ and with full compatibility I mean. Some flag, switch, whatever. Not so. We now know it for sure. I, personally, have nothing at all against good gcc 3.4.x . But you are certainly too well aware of previous opensolaris-discuss'ions in that context ... We now have 100% waterproof reasons to use gcc for the device specific parts. Xorg has been designed with (primarily) gcc/binutils in mind, from the outset on. It may therefore make hardwired assumptions sometimes, which other compiler/as/ld combo's would have handled differently (small, yet important details). Using gcc is the cheapest and most universal "fix". -- Martin Bochnig This message posted from opensolaris.org
