Re: [boost] BOOST_CURRENT_FUNCTION

Subject: Re: [boost] BOOST_CURRENT_FUNCTION
From: Chris Knight (cknite_at_[hidden])
Date: 2008-09-05 16:26:44

On Friday 05 September 2008 3:06:27 pm Emil Dotchevski wrote:
> On Fri, Sep 5, 2008 at 12:16 PM, Simon Atanasyan <atanasyan_at_[hidden]> 
wrote:
> >> Could someone with access to that compiler take a look?
> >
> > Sun C++ supports __func__ under -features=extensions command line option.
>
> That's cool but we still need someone with access to that compiler to
> modify current_function.hpp and test it.
>
> Emil Dotchevski
> Reverge Studios, Inc.
> http://www.revergestudios.com/reblog/index.php?n=ReCode
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

(Un)Luckily I have been spending all day building boost 1.36 using sun studio 
express Jul2008. I have the ability to apply/generate hot fix patch files so 
I'll simply add this patch to my list and post my results shortly. 

I gues this is as good as ever to mention a few major problems with building 
boost using sun studio. 

From the CC man page:
          The -fast macro expands into compilation options that
          may affect other specified options. For example, in the
          following command, the expansion of the -fast macro
          includes -xtarget=native which reverts -xarch to one of
          the 32-bit architecture options.

          Incorrect:
          example% CC -xarch=v9 -fast test.cc

          Correct:
          example% CC -fast -xarch=v9 test.cc

sun.jam apparently has no way of controlling the order in which address-model, 
cxxflags, optimization and the various other options are assembled into the 
final command. This results in garbage binaries. 

My temporary solution was to remove all compiler options from sun.jam and to 
simply pass in cxxflags in its entirety to bjam. This is obviously not ideal. 

A better solution would be to ensure the CC command that is generated is in 
the order:
        <threading> <stlport> <debug-symbols> <optimization> <address-model> 
<cxxflags>
thereby allowing the user to pass in a cxxflags that provides the 
apprpropriate xtarget and xarch flags and not worrying about later args to 
the compiler undoing those settings via macros such as -fast. 

Chris