You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Nicholas Clark (Jira)" <lo...@logging.apache.org> on 2022/04/04 18:44:00 UTC

[jira] [Comment Edited] (LOGCXX-551) CMake documented build option for Boost vs C++17 Implementation for shared_mutex

    [ https://issues.apache.org/jira/browse/LOGCXX-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17517036#comment-17517036 ] 

Nicholas Clark edited comment on LOGCXX-551 at 4/4/22 6:43 PM:
---------------------------------------------------------------

{quote}
    You can build with an earlier standard by setting CMAKE_CXX_STANDARD=11 for example which would cause the check for std::shared_mutex to fail(since it is only in C++17)
    You can pass STD_SHARED_MUTEX_FOUND=0 as you've done already, which could change at some point
    We could introduce a new option called something like LOG4CXX_PREFER_BOOST that would ignore all checks for anything in the std namespace(except for C++11 checks)
{quote}

I think STD_SHARED_MUTEX_FOUND=0 satifies what I want.

I am currently able to build certain components with different C+\+ Standards. The CMake we use sets the default standard at C+\+14, but we have one component that uses C+\+11 still. It's been some time since I checked what standards we could update to, but I think there are certain components we have preventing everything from using C+\+17 or newer. All of our dependencies are built with C+\+17. Aside from this log4cxx issue, there have not been linker issues due to mixed standards until log4cxx. I'm not sure if that means log4cxx could use C+\+17 for some portions and leave the Boost implementation for threading or log4cxx needs to be fully C+\+17. However, it is clear my application would need to be updated to use C+\+17 threading instead of Boost threading at the current full X+\+17 log4cxx support if a setting to switch between Boost thread and shared_mutex goes away.


was (Author: nicholas.clark):
{quote}
    You can build with an earlier standard by setting CMAKE_CXX_STANDARD=11 for example which would cause the check for std::shared_mutex to fail(since it is only in C++17)
    You can pass STD_SHARED_MUTEX_FOUND=0 as you've done already, which could change at some point
    We could introduce a new option called something like LOG4CXX_PREFER_BOOST that would ignore all checks for anything in the std namespace(except for C++11 checks)
{quote}

I think STD_SHARED_MUTEX_FOUND=0 satifies what I want.

I am currently able to build certain components with different C++ Standards. The CMake we use sets the default standard at C++14, but we have one component that uses C++11 still. It's been some time since I checked what standards we could update to, but I think there are certain components we have preventing everything from using C++17 or newer. All of our dependencies are built with C++17. Aside from this log4cxx issue, there have not been linker issues due to mixed standards until log4cxx. I'm not sure if that means log4cxx could use C++17 for some portions and leave the Boost implementation for threading or log4cxx needs to be fully C++17. However, it is clear my application would need to be updated to use C++17 threading instead of Boost threading at the current full c++17 log4cxx support if a setting to switch between Boost thread and shared_mutex goes away.

> CMake documented build option for Boost vs C++17 Implementation for shared_mutex
> --------------------------------------------------------------------------------
>
>                 Key: LOGCXX-551
>                 URL: https://issues.apache.org/jira/browse/LOGCXX-551
>             Project: Log4cxx
>          Issue Type: Wish
>          Components: Build, Documentation
>    Affects Versions: 0.12.1
>            Reporter: Nicholas Clark
>            Assignee: Robert Middleton
>            Priority: Minor
>             Fix For: 0.13.0
>
>
> There was a recent approach to detecting if boost' implementation is needed, but I feel that it is not succinct and cannot be when it comes to linker issues. Referencing PR: [https://github.com/apache/logging-log4cxx/pull/107.|https://github.com/apache/logging-log4cxx/pull/107]
> I have large applications that use shared_mutex, but require boost' implementation as not all components linked are able to use C+\+17 implementation at this time. A problem occurs during linkage when log4cxx is built using C+\+17's implementation but our other component is built using boost' implementation.
>  
> *Workaround:*
> We currently can force cmake into using Boost' implementation by passing:
> {code:java}
> -DSTD_SHARED_MUTEX_FOUND=0{code}
> This isn't a documented 'feature'. I would like a documented approach to this. If -DSTD_SHARED_MUTEX_FOUND=0 is what we should use for this feature request, then it should be documented as such. I am putting forth this issue as current usage is not documented as supported and thus I suspect it may be lost in future commits.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)