Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
3.3.10
-
None
-
None
Description
"MariaDB uses MYSQL_VERSION_ID for its own version which breaks checking for features based on MySQL version. We currently get around this by using LIBMYSQL_VERSION_ID for checking for recent features instead which doesn't work on MariaDB as it was forked before that was added. We could get around this by adding specific code for checking for MariaDB but also there's several other MySQL forks which we would need to do the same for and that can end up being really messy. Ideally MySQL forks should be using that version for the version of MySQL they are compatible with and adding their own macro for their version."
Attachments
Issue Links
- is part of
-
MDEV-28906 MySQL 8.0 desired compatibility
-
- Open
-
- links to
Activity
I looked at the inspircd implementation on https://github.com/inspircd/inspircd/blob/insp4/src/modules/extra/m_mysql.cpp#L342 which is effectively LIBMYSQL_VERSION_ID > 80000 a few time on recent MySQL added/changed features.
The sentiment from https://github.com/inspircd/docs/issues/239#issuecomment-2272862199
[T]here have been some additions to MySQL that have not been replicated in MariaDB. I'm unsure as to whether they plan to make future changes which will make it even more incompatible and I'd like to avoid the situation we ended up in with LibreSSL where we documented support and they ended up breaking so much compatibility that we ended up with a mess of fragile compatibility code in v3 and had to drop support in v4.
Inspird usages relate to CONC-729 (ssl) and CONC-728 mysql_real_connect_dns_srv
Runtime checks aren't the solution to providing a MariaDB C/C and MySQL libmysql as it will compile fail on missing symbols. How ABI compatible is a drop in MariaDB C/C against a MySQL compiled source?
On LIBMYSQL_VERSION_ID, I think the current versioning below MySQL is saving us from compile incompatibilities. There was some versions that used the server version and I think this is where troubles arised. Is this documented somewhere because I don't see it on the usual places https://mariadb.com/kb/en/mariadb-connectorc-types-and-definitions/#macros https://github.com/mariadb-corporation/mariadb-connector-c/wiki/.
Using MARIADB_PACKAGE_ID for supporting MariaDB features is definitely recommended.
I don't see a way we can concretely map LIBMYSQL_VERSION_ID in a way that 100% matches MySQL's compatibility.
MYSQL_VERSION__ID gets used in messages like https://github.com/inspircd/inspircd/blob/insp4/src/modules/extra/m_mysql.cpp#L479 so I see no reason why LIBMYSQL_VERSION_ID wouldn't be used this way elsewhere without any impack on MariaDB versioning.
For SSL a patten of:
#ifdef MYSQL_OPT_SSL_MODE
|
unsigned int ssl = config->getBool("ssl") ? SSL_MODE_REQUIRED : SSL_MODE_PREFERRED; |
mysql_options(connection, MYSQL_OPT_SSL_MODE, &ssl);
|
#endif |
would avoid version checking. For mysql_real_connect_dns_srv I don't an easy way besides version checking.
So the TLDR is LIBMYSQL_VERSION_ID (and MYSQL_VERSION_ID) can't reasonably follow the MySQL unless we pin at the lowest compatible 5.7 version and I don't think that's a good idea. Better documentation on how to achieve a cross compatible interface around multiple MariaDB C/C and MySQL libmysql versions would assist in our engagement with user communities.
rsilen: Do we really need LIBMYSQL_VERSION_ID beside MARIADB_PACKAGE_ID ?
For compile time checking MARIADB_PACKAGE_ID could be used:
#ifdef MARIADB_PACKAGE_ID#if MARIADB_PACKAGE_ID > 30400#define HAVE_PARSEC_PLUGIN#endifFor runtime checking mysql_get_client_version should be used:
{}