Thanks.   For now, I'm using:

#elif (__STDC_VERSION__ >= 199901L) /* C99 */ || \
    (defined(__SUNPRO_C) && defined(__C99FEATURES__))
#  define INLINE inline

and

#  if (__STDC_VERSION__ >= 199901L) /* C99 */ || \
    (defined(__SUNPRO_C) && defined(__C99FEATURES__))
#   define __FUNCTION__ __func__
#  else
#   define __FUNCTION__ "<unknown>"
#  endif

But with the big push to port lots of open source packages to
OpenSolaris & Sun Studio, it would be very helpful to have a
central list of things like this that people could reference
instead of having to research.

I think Chris had set up a wiki on wikis.sun.com for things like
the Sun Studio wizard flags - would you guys like to add it there
or should we put in the OpenSolaris wiki on genunix.org instead?

A few contributions I can think of from our previous porting work
in X (and I'd love to hear if we got any wrong or could be doing
these better - some of these are several years old, hence the
"Forte" references still):

-- GNU autoconf checks

 - Is Sun Studio compiler in use?

    AC_CHECK_DECL([__SUNPRO_C], [SUNCC="yes"], [SUNCC="no"])

 - Can -xc99 be used?

    # -xc99 is only in Sun/Forte cc 6.2 and later
    # It enables C99-ism's such as inline & C++ comments
    AC_MSG_CHECKING([whether Sun/Forte cc -xc99 option works])
    save_CFLAGS="${CFLAGS}"
    CFLAGS="${CFLAGS} -xc99"
    AC_TRY_COMPILE([inline int foo () {return 0; }],
        [int a = foo();], AC_MSG_RESULT([yes]),
        AC_MSG_RESULT([no])
        AC_MSG_CHECKING([[whether Sun/Forte cc -xc99=%all,no_lib option works]])
        [CFLAGS="${save_CFLAGS} -xc99=%all,no_lib"]
        AC_TRY_COMPILE([inline int foo () {return 0; }],
                [int a = foo();], AC_MSG_RESULT([yes]),
                CFLAGS="$save_CFLAGS -xCC" ; AC_MSG_RESULT([no])))


 - Common compiler flags

   if test "$GCC" = "yes" ; then
    SHAREDLIB_LDFLAGS="-shared"
    DEPEND_CCFLAGS="-MM"
    OPTIMIZER_CFLAGS="-O2"
    OPTIMIZER_CXXFLAGS="-O2"
    WARNING_CFLAGS="-Wall"
   fi

   if test "$SUNCC" = "yes" ; then
    SHAREDLIB_LDFLAGS="-G"
    DEPEND_CCFLAGS="-xM1"
    OPTIMIZER_CFLAGS="-xO4 -xlibmil -xdepend"
    OPTIMIZER_CXXFLAGS="-xO4 -xlibmil"
    WARNING_CFLAGS="-v"
   fi

-- C source code

 - Symbol visibility attributes:

   Note that GCC allows these at the end of function declarations,
   but Sun Studio requires them at the beginning, such as:
   EXPORT void foo(int bar);

#if defined(__GNUC__) && (__GNUC__ >= 4)
# define EXPORT         __attribute__((visibility("default")))
# define HIDDEN         __attribute__((visibility("hidden")))
# define INTERNAL       __attribute__((visibility("internal")))
#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
# define EXPORT         __global
# define HIDDEN         __hidden
# define INTERNAL       __hidden
#else /* not gcc >= 4 and not Sun Studio >= 8 */
# define EXPORT
# define HIDDEN
# define INTERNAL
#endif /* GNUC >= 4 */

 - Weak symbols:

#if defined(__ELF__) && defined(__GNUC__) && (__GNUC__ >= 3)
#define weak __attribute__((weak))
#else
#define weak
#endif

#ifdef __SUNPRO_C
#pragma weak foo
#endif

weak int foo(int bar);


        -Alan Coopersmith-           alan.coopersmith at sun.com
         Sun Microsystems, Inc. - X Window System Engineering


Douglas Walls wrote:
> Alan,
> 
> The compiler default of -xc99=all,no_lib
> is C99 language features, but C90 library behavior.
> 
> -xc99=all gets both C99 language and library features, and results
> in setting __STDC_VERSION__ to 199901L.  C99 library support is
> only available on Solaris 10 and later.
> 
> If all you need are the C99 language features (and I believe that is so),
> the Sun Studio compiler predefines __C99FEATURES__ when these are
> available, such as with the default -xc99=all,no_lib.
> 
> We don't document __C99FEATURES__ as we originally intended it for
> Solaris header file use.  But there is really no reason to limit it
> to any such use, we should document it.
> 
> __C99FEATUES__ was introduced with Sun Studio 10, the first compiler
> to provide full C99 support.
> 
> Sorry, I have no list chronicling when we added each C99 language feature
> to the Sun Studio C compilers.
> 
> Douglas
> 
> Chris Quenelle wrote:
>>
>> -------- Original Message --------
>> Subject: [tools-compilers] #ifdef checks for inline, __func__,    etc in 
>> Sun Studio?
>> Date: Tue, 10 Jun 2008 15:40:50 -0700
>> From: Alan Coopersmith <Alan.Coopersmith at Sun.COM>
>> To: tools-compilers at opensolaris.org
>>
>> I'm working on improving Sun Studio support in one of the open-source
>> packages we ship in OpenSolaris & Solaris.
>>
>> Right now it has #ifdef's such as:
>>
>> #if defined(__GNUC__)
>> #  define INLINE __inline__
>> #elif defined(__MSC__)
>> #  define INLINE __inline
>> #elif defined(_MSC_VER)
>> #  define INLINE __inline
>> #elif defined(__ICL)
>> #  define INLINE __inline
>> #elif defined(__INTEL_COMPILER)
>> #  define INLINE inline
>> #elif defined(__WATCOMC__) && (__WATCOMC__ >= 1100)
>> #  define INLINE __inline
>> #else
>> #  define INLINE
>> #endif
>>
>> #if defined(__VMS)
>> # define __FUNCTION__ "VMS$NL:"
>> #elif __STDC_VERSION__ < 199901L
>> # if ((!defined __GNUC__) || (__GNUC__ < 2)) && (!defined __xlC__) && \
>>      (!defined(_MSC_VER) || _MSC_VER < 1300)
>> #  define __FUNCTION__ "<unknown>"
>> # endif
>> #endif
>>
>> What are the right checks for enabling inline & __func__ in Sun Studio?
>> I would have thought checking for __STDC_VERSION__ >= 199901L would be
>> enough, but it appears that the default value of __STDC_VERSION__ in
>> Studio 12 is only 199901L, despite the documentation saying that
>> -xc99=all,no_lib is default (and giving no information I could see
>> on what that means for __STDC_VERSION__).
>>
>> Do I just need to add something like:
>>
>> #elif defined(__SUNPRO_C) && (__SUNPRO_C > 0x0550)
>>
>> and if so is there any list of what versions support what features
>> without having to manually compare the last 10 versions worth of compiler
>> docs on docs.sun.com?
>>
> _______________________________________________
> tools-compilers mailing list
> tools-compilers at opensolaris.org



Reply via email to