Do you have to use Boost 1.66? System is header-only in Boost 1.69 and later. For the time being, yes. The update is not planned yet.

Is there a workaround that can be used in Boost 1.66 to achieve that?Or are there any consequences with the following approach that I'm thinking to use? :

-DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED Thanks,Ashish

On Monday, 25 October, 2021, 11:24:15 pm IST, Peter Dimov via Boost wrote: Ashish Singh wrote:

Hi All,

In my application, I'm trying to use Boost ASIO via boost 1.66 and defining the following two macros in the Makefile. Basically trying to use the header-only approach.

CFLAGS += \ -DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED But then I came across this thread: https://lists.boost.org/Archives/boost/2017/10/239106.php "In header only mode, multiple instances may appear and thus no longer be proper singletons. Stuff breaks in this situation, badly." Is the above applicable to 1.66 too?How can I safely use the header-only approach in boost 1.66?

Do you have to use Boost 1.66? System is header-only in Boost 1.69 and later. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

I see.

Whether this will create problems with duplicate category instances depends on whether and how your program uses dynamic libraries that also use Boost.System and if so, whether these libraries under POSIX use hidden visibility. So, does that also mean that the problems with duplicate category instances caused by a scenario like above, will NOT occur if header-only approach is used in Boost 1.69 and later? Thanks,Ashish

On Tuesday, 26 October, 2021, 12:00:27 am IST, Peter Dimov wrote: Ashish Singh wrote:

  >Do you have to use Boost 1.66? System is header-only in Boost 1.69 and

...

later.

For the time being, yes. The update is not planned yet.

Is there a workaround that can be used in Boost 1.66 to achieve that? Or are there any consequences with the following approach that I'm thinking to use? :

...

-DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED

Defining BOOST_ERROR_CODE_HEADER_ONLY is the correct way to switch Boost.System 1.66 to header-only mode. Whether this will create problems with duplicate category instances depends on whether and how your program uses dynamic libraries that also use Boost.System and if so, whether these libraries under POSIX use hidden visibility.

Thank you so much Peter, for your time and information! My app does use couple of libraries which also use boost by headers. Seems like updating the boost version to >= 1.69 can't be avoided anymore. Thanks,Ashish On Tuesday, 26 October, 2021, 12:20:46 am IST, Peter Dimov wrote: Ashish Singh wrote:

I see.

...

Whether this will create problems

...

with duplicate category instances depends on whether and how your program uses dynamic libraries that also use Boost.System and if so, whether these libraries under POSIX use hidden visibility.

So, does that also mean that the problems with duplicate category instances caused by a scenario like above, will NOT occur if header-only approach is used in Boost 1.69 and later?

Yes, that's correct. Boost 1.69 and later do not suffer from these issues.

Ashish Singh wrote:

Hi Peter,

Forgot to ask:

For Boost 1.69 and later, does the "way" to use the header-only approach remain the same as below?

CFLAGS += \ -DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED

1.69 is always header-only, so the BOOST_ERROR_CODE_HEADER_ONLY macro has no effect. It doesn't hurt to define it though.