It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, I'm looking at http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo.... Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, I'm looking at http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo....
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Not possible I suspect: it relies on the compiler supporting the non-standard __function__ symbol. John.
On Thu, Sep 4, 2008 at 1:24 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Emil Dotchevski wrote:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, I'm looking at
http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo....
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Not possible I suspect: it relies on the compiler supporting the non-standard __function__ symbol.
Well, current_function.hpp has support for many compilers, using whatever implementation-specific symbol is available. I can see that it doesn't specifically address the Sun compiler. Could someone with access to that compiler take a look? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Thu, Sep 4, 2008 at 9:08 PM, Emil Dotchevski <emil@revergestudios.com> wrote:
On Thu, Sep 4, 2008 at 1:24 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Emil Dotchevski wrote:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, I'm looking at
http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo....
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Not possible I suspect: it relies on the compiler supporting the non-standard __function__ symbol.
Well, current_function.hpp has support for many compilers, using whatever implementation-specific symbol is available. I can see that it doesn't specifically address the Sun compiler.
Could someone with access to that compiler take a look?
Sun C++ supports __func__ under -features=extensions command line option. -- Simon Atanasyan
On Fri, Sep 5, 2008 at 12:16 PM, Simon Atanasyan <atanasyan@gmail.com> 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
On Friday 05 September 2008 3:06:27 pm Emil Dotchevski wrote:
On Fri, Sep 5, 2008 at 12:16 PM, Simon Atanasyan <atanasyan@gmail.com> 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
Hi Chris.
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.
If this is so, then please modify the sun.jam toolset to construct the command line with parameters in a suitable order and post a patch to the Boost Build mailing list. That toolset module is the only one constructing the command line and has complete control over it so which ever ordering you need should be relatively easy to implement. If there are any problems - ask the questions on the Boost Build mailing list. Thank you. Best regards, Jurko Gospodnetić
On Friday 05 September 2008 3:06:27 pm Emil Dotchevski wrote:
On Fri, Sep 5, 2008 at 12:16 PM, Simon Atanasyan <atanasyan@gmail.com> 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.
__func__ does work when supplied with -features=extensions in express Jul-2008, Feb-2008 and 12. Since these are the only versions that have any chance whatsoever of building boost it's a pretty safe change however it will require changes to sun.jam to add that command line option to cxxflags. Chris
Emil Dotchevski:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, ...
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Google tells me that __func__ might work on some Sun C++ versions, but I don't have access to the compiler and can't check. :-)
On Thu, Sep 4, 2008 at 10:03 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Emil Dotchevski:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, ...
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Google tells me that __func__ might work on some Sun C++ versions, but I don't have access to the compiler and can't check. :-)
Sun C++ supports __func__ under -features=extensions command line option. -- Simon Atanasyan
Simon Atanasyan:
On Thu, Sep 4, 2008 at 10:03 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Emil Dotchevski:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, ...
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Google tells me that __func__ might work on some Sun C++ versions, but I don't have access to the compiler and can't check. :-)
Sun C++ supports __func__ under -features=extensions command line option.
Is there a way to detect that -features=extensions is in effect and __func__ is supported? Does -features=extensions define a corresponding macro, or if it doesn't, is __func__ itself detectable via #ifdef __func__?
On Friday 05 September 2008 4:48:07 pm Peter Dimov wrote:
Simon Atanasyan:
On Thu, Sep 4, 2008 at 10:03 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Emil Dotchevski:
It appears that BOOST_CURRENT_FUNCTION returns '(unknown)' on sun-5.7, sun-5.8 and sun-5.9, ...
Is this a bug, or is BOOST_CURRENT_FUNCTION not possible on that compiler?
Google tells me that __func__ might work on some Sun C++ versions, but I don't have access to the compiler and can't check. :-)
Sun C++ supports __func__ under -features=extensions command line option.
Is there a way to detect that -features=extensions is in effect and __func__ is supported? Does -features=extensions define a corresponding macro, or if it doesn't, is __func__ itself detectable via #ifdef __func__?
I can't find any way documented or otherwise. It appears to enable the acceptance of __func__ somewhere in the lex/parse stage and does not enable any corresponding macro. The only way I can think of involves the standard compiles/fails approach. Chris
On Sat, Sep 6, 2008 at 1:48 AM, Peter Dimov <pdimov@pdimov.com> wrote:
Is there a way to detect that -features=extensions is in effect and __func__ is supported? Does -features=extensions define a corresponding macro, or if it doesn't, is __func__ itself detectable via #ifdef __func__?
There is no (even undocumented) way to detect this. -- Simon Atanasyan
participants (6)
-
Chris Knight -
Emil Dotchevski -
John Maddock -
Jurko Gospodnetić -
Peter Dimov -
Simon Atanasyan