rspamd @3.1: builds failing for macOS 10.12 and earlier

[mascguy (Christopher Nielsen)]

There are a few different compilation errors, though at least some appear to suggest the C++ standard isn't being correctly set to 2017. But not sure whether that's the cause, based on compilation arguments, etc.

Error on 10.13 and 10.12:

rspamd-3.1/src/libserver/composites/composites.cxx:26:10: fatal error: 'variant' file not found
#include <variant>
         ^~~~~~~~~

Error on 10.11:

rspamd-3.1/contrib/libev/ev.c:4133:34: error: use of undeclared identifier 'have_monotonic'
            if (ecb_expect_true (have_monotonic)) {
                                 ^

​https://ports.macports.org/port/rspamd/builds/

[mascguy (Christopher Nielsen)]

Steve, any thoughts on this? (Not an emergency, but don't want it to be forgotten.)

[essandess (Steve Smith)]

Replying to mascguy:

Steve, any thoughts on this? (Not an emergency, but don't want it to be forgotten.)

My best guess is that this is an upstream issue and that anyone who needs this should request upstream assistance. I know that rspamd’s author builds using very recent macOS and Xcode versions, and it wouldn’t surprise me if older versions are unsupported, or the answer is to use an up-to-date system.

I do not have access to any machines that are pre-macOS 12.

[aeiouaeiouaeiouaeiouaeiouaeiou]

I created a draft pull request and keep encountering an error after successful compilation: ​https://github.com/macports/macports-ports/pull/17192

[ryandesign (Ryan Carsten Schmidt)]

In 9a483f03cde8ec17fc373a354931096a1c423cfa/macports-ports (master):

rspamd: Requires C++20

See: #63785

[mascguy (Christopher Nielsen)]

It looks like builds are failing for older macOS releases, due to missing functionality. Use of legacysupport will help, but open_memstream presumably will require a compatibility lib like this:

​https://piumarta.com/software/memstream/

The latter might be worth adding to legacysupport as well.

CC: @kencu and @cjones

Anyhow, I'll take a closer look at all of this eventually...

[Christopher Nielsen <mascguy@…>]

In c7c1275034bf05247cd5e44b10325ff747ae5756/macports-ports (master):

legacy-support-devel: update to 20230701 commit

• Add support for open_memstream

See: ​https://github.com/macports/macports-legacy-support/pull/59
See: #63785

[Christopher Nielsen <mascguy@…>]

In e4c353f6d5537de1f99603fd8d7f90d30c2c9e95/macports-ports (master):

rspamd: use legacysupport, for open_memstream
See: #63785

[mascguy (Christopher Nielsen)]

Apparently I'm not yet caffeinated enough this morning, as legacysupport won't help just yet: open_memstream has been added to legacy-support-devel, but not legacy-support. Lol

But once it's been added to the latter, I'll queue rebuilds for this port.

[cjones051073 (Chris Jones)]

I just released legacy support 1.0.11 and updated the port.

[cjones051073 (Chris Jones)]

I just scheduled rebuilds of rspamd so please follow these to see how they fare.

[mascguy (Christopher Nielsen)]

Replying to cjones051073:

I just scheduled rebuilds of rspamd so please follow these to see how they fare.

It looks like the port is still failing, albeit due to the apparent lack of fmemopen for older macOS releases. However, there is a simple implementation here - based on funopen, along with an Apache 2.0 license - which we can add to macports-legacy-support:

​https://github.com/tmm1/fmemopen

Assuming there aren't any objections (?), I'll add that to my to-do list.

[Christopher Nielsen <mascguy@…>]

In 0b67cf1c08831cc54340b7be7c6ec0ad774b91cf/macports-legacy-support (master):

stdio.h: add fmemopen (OS X < 10.13)

• Credit: FreeBSD Project
• License: BSD

See: #63785

[Christopher Nielsen <mascguy@…>]

In 900db870294d70f271d1ca7820e9bd49d069f819/macports-ports (master):

legacy-support-devel: update to 20230705 commit
stdio.h: add fmemopen (OS X < 10.13)

• Credit: FreeBSD Project
• License: BSD

See: #63785

[Christopher Nielsen <mascguy@…>]

In b395f71013212e625fb96051bcc9a31aa0b5bd26/macports-ports (master):

rspamd: use macports-libcxx
See: #63785

[mascguy (Christopher Nielsen)]

We're getting closer to fixing the build: The previous updates have solved many of the issues, with the remaining ones in the main top-level client cxx file src/client/rspamc.cxx:

rspamd/work/rspamd-3.5/src/libutil/cxx/util.hxx:101:48: error: no type named 'size_type' in 'std::allocator<char>'
        using size_type = typename std::allocator<T>::size_type;
                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~

In file included from rspamd/work/rspamd-3.5/src/client/rspamc.cxx:24:
/opt/local/include/libcxx/v1/vector:482:30: error: 'reference' is a protected member of 'std::__vector_base<char, rspamd::secure_mem_allocator<char>>'
    typedef typename __base::reference               reference;
                             ^

/opt/local/include/libcxx/v1/vector:483:30: error: 'const_reference' is a protected member of 'std::__vector_base<char, rspamd::secure_mem_allocator<char>>'
    typedef typename __base::const_reference         const_reference;
                             ^

/opt/local/include/libcxx/v1/vector:485:30: error: 'difference_type' is a protected member of 'std::__vector_base<char, rspamd::secure_mem_allocator<char>>'
    typedef typename __base::difference_type         difference_type;
                             ^

/opt/local/include/libcxx/v1/vector:486:30: error: 'pointer' is a protected member of 'std::__vector_base<char, rspamd::secure_mem_allocator<char>>'
    typedef typename __base::pointer                 pointer;
                             ^

/opt/local/include/libcxx/v1/vector:487:30: error: 'const_pointer' is a protected member of 'std::__vector_base<char, rspamd::secure_mem_allocator<char>>'
    typedef typename __base::const_pointer           const_pointer;
                             ^

@kencu, is our version of macports-libcxx relatively recent, vis-a-vis upstream? Particularly related to C++ 2020 additions/changes?

[kencu (Ken)]

not the very newest, but newer than 10.13’s libcxx.

NB, see

​https://github.com/boostorg/wave/issues/84

​https://github.com/boostorg/wave/commit/c9d096b3cc050adb7fa46f4b61f8e16cc3ffc068

[kencu (Ken)]

we may have an issue that we need to ponder…

when using macports-libcxx with a macports-clang that is newer than macports-libcxxx, we probably want to use the newer of the cxx headers, ie the ones in macports-clang.

those headers have not had their availability info modified, however…l

[mascguy (Christopher Nielsen)]

Replying to kencu:

when using macports-libcxx with a macports-clang that is newer than macports-libcxxx, we probably want to use the newer of the cxx headers, ie the ones in macports-clang.

those headers have not had their availability info modified, however…

Ah yep, that would be great! Work-wise, what needs to be done for that?