port mysql8 @8.0.21 fails to build on less than macOS 10.12 due to system libc++ being too old

[wadjei]

I'm unable to build and install the current mysql8 port on my Mavericks 10.9 system.

I have checked out 943ed0fa27 from the repo and have been able to successfully build and install mysql8 and mysql8-server @8.0.20_0.

When I check out HEAD (master) on the repo and try the same, I get...

helium:mysql8 will$ sudo port install
--->  Computing dependencies for mysql8
--->  Fetching archive for mysql8
--->  Attempting to fetch mysql8-8.0.21_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/mysql8
--->  Attempting to fetch mysql8-8.0.21_0.darwin_13.x86_64.tbz2 from https://packages.macports.org/mysql8
--->  Attempting to fetch mysql8-8.0.21_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/mysql8
--->  Fetching distfiles for mysql8
--->  Verifying checksums for mysql8
--->  Extracting mysql8
--->  Applying patches to mysql8
--->  Configuring mysql8
Warning: -----------------------------------------------------------------------
Warning: The port 'mysql8' uses the cxx11 PortGroup which is deprecated.
Warning: Please instead specify the required c++ standard directly using
Warning:     compiler.cxx_standard  2011
Warning: replacing 2011 with newer standards (e.g. 2014, 2017) as required.
Warning: For more details see https://trac.macports.org/wiki/CompilerSelection
Warning: -----------------------------------------------------------------------
--->  Building mysql8
Error: Failed to build mysql8: command execution failed
Error: See /opt/local/var/macports/logs/_Users_will_macports-ports_databases_mysql8/mysql8/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port mysql8 failed

I'll attach the output of main.log

[wadjei]

content of /opt/local/var/macports/logs/_Users_will_macports-ports_databases_mysql8/mysql8/main.log after failed build attempt

[chrstphrchvz (Christopher Chavez)]

The same error occured for the 10.9 builder: ​https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/122774/steps/install-port/logs/stdio

[chrstphrchvz (Christopher Chavez)]

This ticket did not get assigned to the port's maintainer, although they have previously indicated that they might not be able to assist with this port on very old macOS versions.

[kencu (Ken)]

we will be seeing more of these kinds of errors:

mysql-8.0.21/storage/temptable/include/temptable/kv_store.h:76:50: error: 'shared_timed_mutex' is unavailable: introduced in macOS 10.12
      std::conditional_t<std::is_same<Lock, std::shared_timed_mutex>::value,
                                                 ^

libcxx has been removing workarounds that existed for older systems, and instead marking certain features as unavailable prior to specific OS versions.

[chrstphrchvz (Christopher Chavez)]

Indeed this affects up to 10.11; the Travis CI 10.11 builder ​failed for a ​PR I have open, and ​port health shows failure for 10.11 and earlier.

[kencu (Ken)]

Short term solution might be to rewrite mysql to not use those calls (ugh).

Longer term -- install a new libc++.dylib for MacPorts to use, either in parallel with the system libc++.dylib, or replacing the system one (also ugh).

Things that can might build with gcc, where libstdc++.dylib is already very current and updated frequently.

[mf2k (Frank Schima)]

In the future, please add the port maintainer(s) to Cc (port info --maintainers mysql8), if any.

[kencu (Ken)]

best thing to do right now is hold back the version on < 10.12. See <​https://github.com/macports/macports-ports/commit/128bccde6a70c292fec60cd7ba8186e8c7d89d85#diff-f49ca2ea72c829ea3187b231e55ed43c>

[chrstphrchvz (Christopher Chavez)]

Pinning the version is particularly non-ideal for a port that receives security updates often; I would be more inclined to check ${os.major} and refuse to build on 10.11 or earlier in this case. (Security risks are probably already compounded by running outdated/insecure OS versions.)

I would be curious if there's an alternative non-EOL MySQL-like port to recommend instead, but it seems a number of them currently have problems building on 10.11 and earlier; the only working one I'm aware of is mariadb-10.1 (which is EOL in a few months).

[kencu (Ken)]

IMHO - people who want to set up an older, no longer current system to install wordpress on for their daughter's blog (for example), keep it behind a firewall, and serve up the site on a shared port through their router -- don't mind if that system is not state of the art in the very very very latest mysql patches.

but that's me. I don't have any systems that are fully exposed to the open internet.

BTW -- if anyone from the NSA is out there trying to set up a secure MySQL database to hold the nation's secrets from foreign countries -- please, don't do it on macOS 10.9.

[kencu (Ken)]

And yes, they maybe should just dump MacOSX and install Ubuntu 20.04 instead -- but having done that on a number of systems now, that is 1000 hours worth of setup for most people, when you actually get into doing it, working through all the glitches, figuring out UFW, and the cryptic ways of Linux -- which sure everyone should learn, maybe -- but just aren't going to.

[kencu (Ken)]

Well there is one thing to ponder here -- MacPorts has always valued security, and uses that as a point of difference when compared to some other package managers available for macOS. It is important to keep that reputation.

If it cannot be considered secure, for whatever reason including holding back versions of software on older systems, then that would be an issue to be debated on the dev list and possibly a reason to dump all port version holdbacks if it is felt that is the only way to keep up the current excellent security reputation. Or at least add notes or warnings indicating a holdback, etc.

There are already lots of holdbacks in the port tree -- and some of our core libraries are unfortunately years out of date (which is likely a bigger problem).

[chrstphrchvz (Christopher Chavez)]

As of [df5c9df1d7/macports-ports] mariadb-10.2 and mariadb-10.3 should work on 10.6 and later, mariadb-10.4 should work on 10.7 10.6 (64-bit) and later, and mariadb-10.5 should work on 10.9 and later. Can we make mysql8 require 10.12 to build, and recommend affected users migrate to a MariaDB port instead (and hope that updates don't pose too much of an issue)?

[kencu (Ken)]

mysql8 installs on 10.6, and on any 10.7-10.12's that update their libc++ (which they are all going to have to do pretty soon if they want to stay alive... ).

Why not leave them to do so?

[BjarneDMat]

@chrstphrchvz I've got mariadb-10.5 running on 10.6 Snow Leopard

@kencu So in order to -possibly- get mysql8 to compile under 10.6 Snow Leopard, one has to install libc++ eg like this :
port -cuNp upgrade --enforce-variants libcxx +emulated_tls -universal +replacemnt_libcxx
#=> find /Developer -name 'libc++.dylib'
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc++.dylib

Having done that, mysql8 @8.0.23 fails to compile log here : ​https://macports.mathiesen.info/logs/databases/mysql8/main.log3

According to ​https://mariadb.org/wp-content/uploads/2020/09/migration_serverfest2020.pdf slide #9, there's no current mariadb equivalent to mysql8

[kencu (Ken)]

I have enabled libcxx-11 in the current installation of clang-11 (it just fits there better).

It is brand new. I don't think anyone has used it for anything yet.

There are possible issues with using a newer libc++.dylib on older MacOS versions -- the issue is called an "ODR violation" if you would like to google it and read up on it.

libc++ and libc++abi are currently installed in the lib directory of llvm-11, and tucked away with an @rpath link in them.

So - go nuts, boys. Kick the tires. See what works, what doesn't work, how we might (or might not) be able to use this to solve our troubles.

Expect problems, and be prepared to come up with solutions too...

[kencu (Ken)]

Replying to BjarneDMat:

Having done that, mysql8 @8.0.23 fails to compile log here : ​https://macports.mathiesen.info/logs/databases/mysql8/main.log3

According to ​https://mariadb.org/wp-content/uploads/2020/09/migration_serverfest2020.pdf slide #9, there's no current mariadb equivalent to mysql8

your build error is:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_mysql8/mysql8/work/mysql-8.0.23/storage/temptable/include/temptable/kv_store.h:76:50: error: 'shared_timed_mutex' is unavailable: introduced in macOS 10.12

Here is the reason, and the solution:

On macOS, Apple and their llvm-related engineers believe you would never change the libc++.dylib that comes with the system. That's pretty fair, most everyone would not change it. But -- we're not everyone, are we? We have installed a version of libc++.dylib on 10.6.8 that is *newer* than the one that comes with 10.12. Apple never thought we would do that.

Apple has helpfully listed certain functions, such as shared_timed_mutex as not existing until macOS 10.12, and will give you an error (as you see) if you try to use those functions on systems older than that. They don't do a functional test for them -- they own the OS after all -- they do a system version test for them. But -- we have a newer libc++.dylib, and that doesn't apply to us.

For clang-8.0 and clang-9.0, I patched out that test like this <​https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/files/5005-MacPorts-only-patch-libcxx-includes-disable-availability-tests.diff>. But -- clang-7.0 is old, and I didn't do that patch in clang-7.0. My Bad.

Now here comes the perfect storm -- we (I) forced mysql8 to build with clang-7.0 because (back then) clang-8+ failed to build it. Then after I did that, mysql8 added the new function, which clang-7.0 says is not available (but really it is ). Ergo build error on 10.6.8.

SHORT story:

On SnowLeopard, do this <​https://github.com/macports/macports-ports/blob/master/lang/llvm-9.0/files/5005-MacPorts-only-patch-libcxx-includes-disable-availability-tests.diff> in your clang-7.0 headers and it will build.

[chrstphrchvz (Christopher Chavez)]

Is this an issue to try legacysupport.use_mp_libcxx yes for?

[chrstphrchvz (Christopher Chavez)]

Replying to chrstphrchvz:

Is this an issue to try legacysupport.use_mp_libcxx yes for?

Added to PR: ​https://github.com/macports/macports-ports/pull/12638

[chrstphrchvz (Christopher Chavez)]

Replying to chrstphrchvz:

Is this an issue to try legacysupport.use_mp_libcxx yes for?

New PR opened: ​https://github.com/macports/macports-ports/pull/12644

[chrstphrchvz (Christopher Chavez)]

As of [1cdb3d250f/macports-ports] this port requires macOS 10.13. The idea to use newer libc++ was rejected. This ticket can be closed.