I am still desperately trying to make mpg123 work properly with Sun Studio (12.1, be it on Solaris or Linux...). After working around a showstopper bug [mpg123 bug 3004396|http://sourceforge.net/tracker/?func=detail&aid=3004396&group_id=135704&atid=733194] the Sun compiler still does not want to play.
The problem it has now: It doesn't preprocess .S files as expected.
We have some machinery to make our stand-alone assembly code portable, namely some name mangling that boils down to prepending an underscore or not. So, there is something along
ASM_NAME(bla)
ASM_VALUE(blu)
which either expands to simply "bla" or "_bla" , or "$bla" / "$_bla" (or some other funky mangling). This needs token pasting as supported by the C preprocessor, and also documented for Sun Studio. This simple example is derived from the Sun docs:
#define glue(a,b) a ## b
glue(x, 1)
Now I get different results when putting that fragment into a C file (.h, .c) or an assembly file (.S)
bash-3.00$ cpp glue.S
x1
bash-3.00$ cpp glue.c
# 1 "glue.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "glue.c"
x1
bash-3.00$ which cpp
/usr/sfw/bin/cpp
bash-3.00$ $CC -E glue.S
# 1 "glue.S"
x ## 1
bash-3.00$ $CC -E glue.c
# 1 "glue.c"
# 2
x1
#ident "acomp: Sun C 5.10 SunOS_i386 2009/06/03"
The crucial thing here is the output of $CC -E (CC being set to studio12.1's cc). The token pasting is not executed and that gives a syntax error later on.
Since the build process just hands the .S files to the compiler (which works best, considering other platforms), this is the kind of preprocessing that is applied. This is no problem for other compilers (GNU, intel, open64) and I thought that's de-facto standard behavior.
Now, is there some rationale behind normal macro directives like #ifdef and substitution as such are applied to .S files, but token pasting is left out? Is it a bug? This seems to be the last barrier that prevents mpg123 from working out of the box on x86.