https://bugs.exim.org/show_bug.cgi?id=2165
--- Comment #9 from Kris Karas <bugs-a17@???> ---
(In reply to Phil Pennock from comment #6)
> % vagrant up stretch
> % vagrant ssh stretch
> $ sudo apt-get install software-properties-common dirmngr
> $ sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com
> [...]
Ducky. Did that at least come with a sutiable BEvERage? :-)
> So far, no client headers.
I wrote a hasty, stupid program to dump the defined headers for various
flavours of MySQL/MariaDB - attached above. There are a few take-aways:
* Simply including <mysql.h> will always define MYSQL_VERSION_ID.
There is no need to #include <mysql_version.h> as mysql.h does that for you.
* There is no need to #include <mariadb_version.h> similarly, unless you
really need MARIADB_CLIENT_VERSION_STR && your mariadb version is between
10.2.0 and 10.2.6
> [...] I think their idea of compatibility is not compatible with my idea
> of compatibility. [...] If things keep changing like this then clearly
> we're not using the supported public APIs.
Exactly. In addition to Exim, I debugged many other pieces of software and
submitted several patches to make them all compile against mariadb-10.2.8+.
It was pretty clear that they were referencing elements inside mysql/mariadb
headers that were private to the server. The my_global.h and my_sys.h
headers are not supposed to be used by client code, but references to them
were everywhere.
Client code is /supposed/ to be able to compile using only the headers and
library from the "MySQL Connector/C" package; if you look at the headers
provided by that, they are a tiny fraction of what is included in the
normal mysql-x.y.z and mariadb-x.y.z releases.
> I am struggling to find any documentation aimed at client developers on how
> to use the API, to figure out what we should be doing.
The headers in the top-level include directory of mariadb-10.2.8 and/or those
published by "MySQL Connector/C" is a good start. Unless a client is doing
something that requires very intimate knowledge of the innards of its SQL
server, then the only two header files a client /should/ need are mysql.h
and (if you need more verbose error responses) errmsg.h
> Failing that, I _think_ that the correct solution is:
>
> #include <mysql.h>
> #ifdef LIBMARIADB
> # include <mariadb_version.h>
> #else
> # include <mysql_version.h>
> #endif
Not needed. As mentioned above and in the attached output from my test
program, <mysql.h> will automatically include the version info.
An even better solution than my first patch is to format MYSQL_VERSION_ID
instead of looking at MARIADB_CLIENIT_VERSION_STR and/or MYSQL_SERVER_VERSION.
My initial patch was just a quick-and-dirty to compile using the smallest
diff. The patch by Andrey in comment #7 could be simplified quite a bit
more with something like this:
fprintf(f, "Library version: MySQL: Compile: %d.%d.%d\n"
" Runtime: %s\n",
(MYSQL_VERSION_ID/10000),
(MYSQL_VERSION_ID/100)%100,
(MYSQL_VERSION_ID%100),
mysql_get_client_info());
> ... is it plausible that instead of pulling in server/, we should just
> change src/EDITME and the examples for LOOKUP_INCLUDE to say something like:
>
> ## If using MariaDB 10.2.8 or newer, then:
> # LOOKUP_INCLUDE=-I/usr/include/mysql -I/usr/include/mysql/server
Yes, because if mariadb-10.2+ is /not/ compiled with "compatibility" enabled,
then the include files go in /usr/include/mariadb and not /usr/include/mysql,
and the mysql.h becomes mariadb.h, etc.
--
You are receiving this mail because:
You are on the CC list for the bug.
