weird boost/mysql issue preventing snort upgrade after selfupdate

[TheLastLovemark]

I just performed another self update at the instruction of kencu for ​this ticket.

As soon as the self update completed, i performed a port outdated and saw mysql57, mysql57-server and snort were outdated, among others like tesseract and its dependent ports. Tesseract et al upgraded with no problem.

When I tried to upgrade snort, mysql and boost were upgraded as snort is dependent on both.

The mysql57 upgrade failed because boost was active. I deactivated boost, cleaned mysql57 and ran an upgrade of mysql57 directly. That faild because boost was deactivated. The log of the second fail is attached.

[TheLastLovemark]

mysql57 main.log

[Schamschula (Marius Schamschula)]

See: #58081

[TheLastLovemark]

I don't know how to "use conflicts build"

Am I supposed to use a specific flag when I type the port install command?

Thank you for the guidance though

[Schamschula (Marius Schamschula)]

Replying to TheLastLovemark:

I don't know how to "use conflicts build"

Am I supposed to use a specific flag when I type the port install command?

Thank you for the guidance though

If you try to install mysql57, you will get a message telling you what to do. In this case you need to deactivate boost, something like:

sudo port -f deactivate boost

Enter the command it gives you. You can reactivate boost after upgrading mysql57:

sudo port activate boost

[TheLastLovemark]

I've tried that already, i.e. the last line of the initial report above.

[Schamschula (Marius Schamschula)]

Replying to TheLastLovemark:

I've tried that already, i.e. the last line of the initial report above.

Did you run sudo port clean mysql57 before trying again?

[TheLastLovemark]

NEW mysql57 main.log

[TheLastLovemark]

yes.

I did it again as root just to be sure. and uninstalled boost 1.6x completely so that the version packaged with mysql57 (1.59?) is the only one on the system, and it failed again. New mysql57 main.log

[michaelld (Michael Dickens)]

What does the following return:

port provides /opt/local/include/google/protobuf/message.h

[TheLastLovemark]

/opt/local/include/google/protobuf/message.h is provided by: protobuf3-cpp

[michaelld (Michael Dickens)]

OK that's what I thought. Took me a bit to track that down & install it for testing.

So there are a few issues here:

(1) mysql57 is opportunistically finding and using protobuf3-cpp . I think this feature can be disabled via the cmake commandline, and really it should be a variant / optional.

(2) protobuf3-cpp API (header) require C++11 for building, but mysql57 when building the plugin that uses protobuf3-cpp isn't using C++11 ... it's not specifying any C++ standard, which with most compilers means C++03 or earlier ... certainly not C++11 yet. Without C++11, this plugin won't build. You can see the errors in the build log associated with this issue:

:info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_mysql57/mysql57/work/mysql-5.7.25/rapid/plugin/x/ngs/include/ngs_common/protocol_protobuf.h:25:
:info:build In file included from /opt/local/include/google/protobuf/message.h:118:
:info:build In file included from /opt/local/include/google/protobuf/arena.h:51:
:info:build /opt/local/include/google/protobuf/arena_impl.h:249:15: error: no type named 'atomic' in namespace 'std'
:info:build   static std::atomic<int64> lifecycle_id_generator_;
...
:info:build /opt/local/include/google/protobuf/arena_impl.h:303:22: warning: rvalue references are a C++11 extension [-Wc++11-extensions]
:info:build   ArenaImpl(ArenaImpl&&) = delete;
:info:build                      ^
:info:build /opt/local/include/google/protobuf/arena_impl.h:303:28: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions]
:info:build   ArenaImpl(ArenaImpl&&) = delete;
:info:build                            ^

And then see also < ​https://en.cppreference.com/w/cpp/atomic/atomic > where it should be noted that std::atomic requires C++11.

[michaelld (Michael Dickens)]

Can you attach the file $(port work mysql57)/build/CMakeCache.txt?

[michaelld (Michael Dickens)]

Another possible issue: The MySql57 CMake script is designed to use the internal protocol buffers source if the user doesn't specify otherwise. There's nothing in the Portfile specifying otherwise, but because 'port' uses lots of MacPorts headers, I'd bet that for the specific plugin C++ files there is a header search path ordering issue, where the MacPorts headers are searched before the internal MySql57 headers. The MySql57 protocol buffers is at version 2.6.1, which probably doesn't require C++11 for building & Hence would work correctly if not for so many issues herein LOL!

[TheLastLovemark]

mysql57 CMakeCache.txt

[TheLastLovemark]

So what do I do?

[michaelld (Michael Dickens)]

Not sure what can be done just yet. MySql57 seems to be a mess internally. You can try sudo port -f deactivate protobuf3-cpp & then clean myqsl57 and try again. This fixed the immediate issue for me, but the build still crashed later.

[michaelld (Michael Dickens)]

See < ​https://github.com/macports/macports-ports/pull/3682 > for a possible patch; this PR fixes the issues for me.

[TheLastLovemark]

I'm not familiar with this way of updating

[michaelld (Michael Dickens)]

If you've familiar with using the patch command, then you can use a PR's generated patch file to test out the PR. If you're not really familiar with patch or how port works behind the scenes, then I'd say to wait this out.

[michaelld (Michael Dickens)]

I went ahead with the merge of this PR. So, you should be able to update your ports & then either install or upgrade this port & hopefully it'll work now.

[michaelld (Michael Dickens)]

Please do report back here success or failure :)

[TheLastLovemark]

ok. It worked. Installs with no issues.

[TheLastLovemark]

Thank you

[michaelld (Michael Dickens)]

Great! YW & thank you for reporting back.