Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.
On Wed, Aug 22, 2012 at 6:58 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.
Boost Exception is a header-only lib, except for the non-intrusive exception_ptr support that is provided for some MSVC versions, which is off by default. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Wed, Aug 22, 2012 at 6:58 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.
Boost Exception is a header-only lib, except for the non-intrusive exception_ptr support that is provided for some MSVC versions, which is off by default.
Then I'm confused. When I build using: bjam cxxflags=-march=native -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr - sEXPAT_LIBPATH=/usr/lib64 --layout=tagged threading=single,multi link=shared stage on fedora 17 x86_64, I got: -rw-rw-r-- 1 nbecker nbecker 1662 Aug 21 10:34 libboost_exception.a -rw-rw-r-- 1 nbecker nbecker 1662 Aug 21 10:44 libboost_exception-mt.a
On Wed, Aug 22, 2012 at 12:26 PM, Neal Becker <ndbecker2@gmail.com> wrote:
On Wed, Aug 22, 2012 at 6:58 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.
Boost Exception is a header-only lib, except for the non-intrusive exception_ptr support that is provided for some MSVC versions, which is off by default.
Then I'm confused. When I build using:
bjam cxxflags=-march=native -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr - sEXPAT_LIBPATH=/usr/lib64 --layout=tagged threading=single,multi link=shared stage
on fedora 17 x86_64, I got:
-rw-rw-r-- 1 nbecker nbecker 1662 Aug 21 10:34 libboost_exception.a -rw-rw-r-- 1 nbecker nbecker 1662 Aug 21 10:44 libboost_exception-mt.a
Right, you don't need to link to this library. It's needed only if you #define BOOST_ENABLE_NON_INTRUSIVE_EXCEPTION_PTR which you probably do not, and certainly should not on Fedora, because the non-intrusive exception_ptr support is currently implemented only on some versions of MSVC. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
2012/8/22 Emil Dotchevski <emildotchevski@gmail.com>:
On Wed, Aug 22, 2012 at 12:26 PM, Neal Becker <ndbecker2@gmail.com> wrote:
On Wed, Aug 22, 2012 at 6:58 AM, Neal Becker <ndbecker2@gmail.com> wrote:
Is it necessary that exception builds only static libs? On many architectures, this would limit it's usefulness.
Boost Exception is a header-only lib, except for the non-intrusive exception_ptr support that is provided for some MSVC versions, which is off by default.
Then I'm confused. When I build using:
bjam cxxflags=-march=native -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr - sEXPAT_LIBPATH=/usr/lib64 --layout=tagged threading=single,multi link=shared stage
on fedora 17 x86_64, I got:
-rw-rw-r-- 1 nbecker nbecker 1662 Aug 21 10:34 libboost_exception.a -rw-rw-r-- 1 nbecker nbecker 1662 Aug 21 10:44 libboost_exception-mt.a
Right, you don't need to link to this library. It's needed only if you #define BOOST_ENABLE_NON_INTRUSIVE_EXCEPTION_PTR which you probably do not, and certainly should not on Fedora, because the non-intrusive exception_ptr support is currently implemented only on some versions of MSVC.
Does that mean that the compilation of boost_exception could/should be disabled for compilers other than MSVC? Cheers, Daniel
On Wed, Aug 22, 2012 at 10:17 PM, Daniel Pfeifer <daniel@pfeifer-mail.de>wrote:
2012/8/22 Emil Dotchevski <emildotchevski@gmail.com>: Does that mean that the compilation of boost_exception could/should be disabled for compilers other than MSVC?
That might be a good idea -- if someone knows how to setup the Jamfile conditionally, I have no problem with that. Thanks, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (3)
-
Daniel Pfeifer -
Emil Dotchevski -
Neal Becker