Skip to content

Switch default to libstdc++, but retain a libc++ CI #6772

Closed
@achamayou

Description

As we started adding support for Azure Linux, it seemed that compatibility with libstc++ was a pre-requisite, because libcxx was not packaged at the time (although it was added soon after. A first change was made in #6552 to allow libstdc++ builds, but retain the libc++ default.

Because libstdc++ is more widespread, is the default on Azure Linux (and most distributions), and is used by piccolo, the intention was to switch long term, but the Ubuntu builds stayed unchanged.

As it emerged that libc++ offered hardening functionality (see #6720), the thinking changed to perhaps staying with libc++. Looking at Azure Linux again revealed that the library was now packaged, and could be used. Fixes linked in #6720 were applied to switch all builds to libc++.

We also found that libc++ contained an issue that was (and will remain for time) the source of spurious AddressSanitizer errors, which was addressed in #6753 by switching the ASAN build to libstdc++. More recently, as the scitt-ccf-ledger project is adding dependencies on C++ libraries such as rego-cpp, which only target libstdc++, the use of libc++ in CCF releases has become a blocker.

As a consequence, I propose that CCF:

  • Switches to libstdc++ in all contexts, as a default.
  • With the exception of a specific CI job building with libc++ and -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_EXTENSIVE, similar to Enable libc++ bound checks #6767.

This will resolve compatibility issues, ASAN warnings, and preserve much of the benefit of hardening, albeit not in production builds. We will not release libc++ builds, the benefits are not proportionate to the additional packaging effort.

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions