There were fixes in 10.2.7/10.2.8, but apparently partial ones, concerning libraries: MDEV-12938, MDEV-13270 and alike.

serg, I don't see if anything has been done about socket, port etc – has it?

Please use the following cmake parameters for Connector/C

-DMARIADB_PORT=number

-DMARIADB_UNIX_ADDR=/path_to_socket/file.sock

The server has (used to have for ages) some magic around the port number. If it's 0, the default port value will use getservbyname("mysql", "tcp"), that is, whatever is written in /etc/services. If it's a positive number, say, 3306, it will be 3306, no matter what /etc/services say.

I don't know if that behavior makes much sense, /etc/services wasn't supposed to be a system configuration file.

• Server headers? I am not sure. Logically, mysql_config should return paths with "/server" suffix, pointing to server headers. But that's a terrible idea, obviously. I can have a bunch of --server-cflags etc options or just let the user append "/server" to --cflags. Neither is particularly attractive...
• --libmysqld-libs — I don't think it's possible. It's the server wrapped in a library, C/C does not know about it.

See it my way:

I have many projects in Fedora using mysql. Historically, they all were using MariaDB under the hood.
Recently, with MariaDB 10.2, it is not a drop-in replacement, not even close.

• client library rename
• header files moves to different locations
• config binary rename (mysql_config -> mariadb_config)
• header files change and rename. ("mariadb_version.h != mysql_version.h" and if symlinked, packages won't compile)

I also made a change in Fedora, where I dropped client library part from 'mariadb' package and started to provide it by 'mariadb-connector-c' package. Which lead me to face different challenges:

• config binary has different values than server one, but only one can be present on the system. (Projects searches for 'mysql_config', not 'mariadb_config')
• I'd mention, that release cycle of CONC/C is a bit ... slower ... and many new changes and fixes provided by new mariadb-10.2.x aren't reflected in the CONC/C until its next release. Which leads to state where server part uses fixed stuff CONC/C don't know about or is still broken.

I'm looking for a "mysql_config" in CONC/C, that could be used for server building too.
I don't know, how the binary gets its values, but I don't see a problem to change them, of they are hardcoded. I mean - you are developer of both - server and client - you know, where the files are.

----------------------

I know, that may not be easy.
However the situation escalated to the point, where user has to decide, which database to use. I'm trying to hold all projects in Fedora on MariaDB, so I face the real issues - like "nobody ever expected to use this software with mariadb, so we hardcoded paths to ...".
The projects either don't use 'mysql_config' at all (rarely), or use only part of it (common), or depends on values given by packager (often, but works well). But nobody will ever use 'mariadb_common', until the appropriate patch is sent to upstream. That is not such a problem, since I can symlink 'mysql_config' to 'mariadb_config'.
But this arises new issues, if those two differ an if I provide only CONC/C one.

Yes, I understand. And — make no mistake — we totally want MariaDB to be as easy to use and create as little problems for distributions as possible.

But what does it mean in a context of this bug report? Support -DMYSQL_UNIX_ADDR=xxx ? I think we can do that easily. Implement magic port=0 behavior as in the server? Doable too. Server headers — I don't like the current situation and I'd be happy to change it, just don't know how. libmysqld? I don't think C/C can do anything about it, but given that MySQL removed embedded library completely, --libmysqld-libs cannot be a compatibility issue, can it?

This bug report is meant to handle only the 'mariadb_config' binary.

As I told, I'm tricked into delivering the binary 'mariadb_config' from CONC/C, while hiding behind symlink 'mysql_config'. (I can't ship the 'mysql_config' from server, since there is already so called symlink)

The issue is - I believe - that because of different output of 'mariadb_config' in CONC/C and 'mysql_config' in server, there can rise issues, when someone would like to build with server.

In simple words - ideally, to 'mariadb_config' from CONC/C to cover all parts, including server and embedded server.

—

I see following simple solutions:
1) You extend the output to cover all the other parts and you will fill them with informations.
2) You add Cmake options, so I - the maintainer - can fill the informations, because I know, where to find what in a mariadb I packed.
I see some possible solutions:
3) The server 'mariadb_config' and 'mysql_config' would hold the same data, I would be placed to some other package (like mariadb-common in Fedora) ,which would be required by mariadb-connector-c-devel.
This assume, the server config binaries could apply to client too.
And I see awfull solutions too:
4) just 'steal' the config binary from server.
something like - ship it with server in some custom hidden location and just copy it at a build time to a CONC/C package. (Please ... don't)

—

Unfortunatelly, I don't know, which options are commonly used by other projects ... some are, some are not. However, all the information should be available at one place. That's what I'm looking for.

To learn developers use such a config binary properly ... is second thing.

What about this approach: https://github.com/MariaDB/server/commit/8fbb50861291f

It'll guarantee that mysql_config always returns same values as mariadb_config

This assumes you don't symlink mariadb_config to mysql_config, but keep both side by side.

mariadb_config will return client (libmariadb) config, while mysql_config will return both client config and embedded server (libmysqld) config.

In general, this is a good idea, how to solve it.

However, it won't help me.

—

1)
I need "mariadb-connector-c" to provide 'mysql_config', no matter what. (either symlink, script or binary).
If it won't be called "mysql_config", other projects won't find it.

2)
Currently I got 'mariadb_config' binary and 'mysql_config' symlink ot it in CONC/C package.
In "mariadb" package I don't have any, beacuse if I had one, it would conflict with the same named file from CONC/C package.

—

So I would need

1)
Reverse approach - edit 'mariadb_config', so in the case the 'mysql_config' is also there, it would inherit its values

OR

2)
Pack both 'mariadb_config' and 'mysql_config' binaries / scripts in CONC/C

1) but that wouldn't work, because you symlink mariadb_config to mysql_config? so it'll just be calling itself in a infinite loop.

but anyway, the problem both with 1) and 2) is that Connector/C is a separate project, a client library, and you build it without the server. It cannot possibly know anything about the server or even if the server exists at all, much less about how it was configured and built. When Connector/C is built from inside the server we have some pass-through's to let C/C see server configuration. But it cannot work when C/C is configured outside of the server.

I can, perhaps, make C/C to install a compatibility symlink mariadb_config->mysql_config. But it won't help you, because it won't have libmysqld-libs option. And it cannot, because only server knows how it was configured.

I'd think the easiest (long-term) approach for you would be to use mariadb-shared packages as compiled from mariadb server source tarball. as a bonus you'll get regular connector/c bugfixes with every server release.

But if you cannot do that anymore, you could remove the symlink and install the small mysql_config shell script instead. Something like that

#!/bin/sh

if test "$1" = "--libmysqld-libs"; then

  echo "-L/usr/mysql/lib  -lmysqld"

else

  mariadb_config "$@"

fi

OK, back to base issue. 'mysql_config' and 'mariadb_config' output differ.

Port number:

• I'd rather set it directly to 3306 in both server and CONC/C

Include dir: (clfags etc.)

• I moved stuff to their new locations in both server and CONC/C.
• That means:
  Client: "/usr/include/mysql", few files in "/usr/include/mysql/mysql"
  Server: four files in "/usr/include/mysql/mysql", rest in "/usr/include/mysql/server"

Libraries:

• both "/usr/lib64/mysql" and "/usr/lib64/mariadb" are fine (symlinked).
• but what about the "-lz" option?
  server: -lmariadb -lpthread -lz -ldl -lm -lssl -lcrypto
  CONC/C: -lmariadb -lpthread -ldl -lm -lssl -lcrypto

Plugins:

• is there a problem having client plugins and server plugins at the same place?
  "/usr/lib64/mariadb/plugin"

Socket:

• already told about. CONCC issue.

—

1) How to set all this up?
(CONCC: -DMARIADB_PORT, ?, ?, -DPLUGIN_INSTALL_DIR, -DMYSQL_UNIX_ADDR)
(server: ?, -DINSTALL_INCLUDEDIR, -DINSTALL_LIBDIR, -DINSTALL_PLUGINDIR, -DMYSQL_UNIX_ADDR)

2) Can you make this consistent between server & CONC/C? (returning the same values, when set up the same)

• if yes, I'd probabbly go for a wrapper, that shows 'mariadb_config' and if 'mysql_config_server' (will need rename) is present, it'll show aditional flags.

—

That could solve it whole, right?
Am I forgetting something?

• port=0 means that port number is taken from /etc/services.
  you want to disable that and set port to 3306?
  it's not possible at the moment, but I'll fix it.

• there should be no server include files in "/usr/include/mysql/mysql".
  what are they?

• missing -lz looks like a bug, consider it fixed

• no problem. it's even desirable, because technically server and
  client plugins can be in the same .so file

• socket: use -DMARIADB_UNIX_ADDR=/var/lib/mysql/mysql.sock

how to set this up.

Server: -DRPM=yes (this should set all paths in "rpm-style")
Client: -DCMAKE_INSTALL_PREFIX=/usr -DMARIADB_UNIX_ADDR=/var/lib/mysql/mysql.sock -DINSTALL_PLUGINDIR=lib64/mariadb/plugin -DINSTALL_INCLUDEDIR=include/mysql -DWITH_EXTERNAL_ZLIB=YES

This worked in my tests

georg could you please review this commit: https://github.com/MariaDB/mariadb-connector-c/commit/7cfe708e282ca1ef4f7e26f240422f7c3761a26f

wlad could you please review these two commits: https://github.com/MariaDB/server/commit/5cbbed6e859477a27d4da3cfd8fcb5c335d6b854 and https://github.com/MariaDB/server/commit/c2a3613162d9ce4af74b15507c212f63e1d05fa6

I need to use some Fedora RPM build macros.

In latest version with the cmake options you wrote, it looks like this:

%build

%cmake . \

       -DCMAKE_BUILD_TYPE=RelWithDebInfo \

       -DCMAKE_SYSTEM_PROCESSOR="%{_arch}" \

       -DINSTALL_LAYOUT=RPM \

\

       -DMARIADB_UNIX_ADDR=/var/lib/mysql/mysql.sock \

       -DMARIADB_PORT=3306 \

\

       -DWITH_EXTERNAL_ZLIB=YES \

       -DWITH_SSL=OPENSSL \

       -DWITH_MYSQLCOMPAT=ON \

\

       -DPLUGIN_INSTALL_DIR="%{_libdir}/mariadb/plugin" \

       -DINSTALL_INCLUDEDIR=%{_includedir}/mysql

That moves everything to correct destination.
At also fixes 'mariadb_config' socket output.

However it returns those 2 options obviously wrong:

  --cflags        [-I/usr//usr/include/mysql -I/usr//usr/include/mysql/mysql]

  --include       [-I/usr//usr/include/mysql -I/usr//usr/include/mysql/mysql]

The include directory tree:

usr

└── include

    └── mysql

        ├── errmsg.h

        ├── ma_list.h

        ├── ma_pvio.h

        ├── mariadb

        │   └── ma_io.h

        ├── mariadb_com.h

        ├── mariadb_ctype.h

        ├── mariadb_dyncol.h

        ├── mariadb_stmt.h

        ├── mariadb_version.h

        ├── ma_tls.h

        ├── mysql

        │   ├── client_plugin.h

        │   ├── plugin_auth_common.h

        │   └── plugin_auth.h

        ├── mysqld_error.h

        └── mysql.h

—

In this comment I talk only about CONC/C and its last release on https://downloads.mariadb.org/.
(Should I try your GitHub content instead?)

mariadb_config treats INSTALL_INCLUDEDIR as relative to basedir (/usr).

I'd agree that it should support absolute paths too, but we probably won't be able to fix it in time for 10.2.10.

Could you specify -DINSTALL_INCLUDEDIR=include/mysql ?

The option to specify absolute path would be highly welcomed.
In Fedora RPM build process it is ideal to use, since nearly every path contains one or more macros, that has different paths for different architectures etc.

I'm currently investigating another issue (this time only on Fedora side) where I hit this "-I/usr//usr/include/mysql/mysql" hard, so I actually patched it for my purposes (but most likely it cannot be used for everyone):

--- mariadb-connector-c-3.0.2-src/mariadb_config/mariadb_config.c.in    2017-07-19 11:31:02.000000000 +0200

+++ mariadb-connector-c-3.0.2-src/mariadb_config/mariadb_config.c.in_patched    2017-10-25 12:32:42.075324299 +0200

@@ -5,8 +5,8 @@

 static char *mariadb_progname;

-#define INCLUDE "-I@CMAKE_INSTALL_PREFIX@/@INSTALL_INCLUDEDIR@ -I@CMAKE_INSTALL_PREFIX@/@INSTALL_INCLUDEDIR@/mysql"

-#define LIBS    "-L@CMAKE_INSTALL_PREFIX@/@INSTALL_LIBDIR@/ -lmariadb "\

+#define INCLUDE "-I@INSTALL_INCLUDEDIR@ -I@INSTALL_INCLUDEDIR@"

+#define LIBS    "-L@INSTALL_LIBDIR@/ -lmariadb "\

                 "@extra_dynamic_LDFLAGS@"

 #define LIBS_SYS "@extra_dynamic_LDFLAGS@"

 #define CFLAGS  INCLUDE

While having following CMAKE options:

       -DINSTALL_LAYOUT=RPM \

       -DINSTALL_BINDIR="%{_bindir}" \

       -DINSTALL_LIBDIR="%{_libdir}" \

       -DINSTALL_INCLUDEDIR=%{_includedir}/mysql \

       -DPLUGIN_INSTALL_DIR="%{_libdir}/mariadb/plugin"

The " -DCMAKE_INSTALL_PREFIX", if used, breaks other stuff for me (moving files to wrong locations), so I'm ommiting it.

INCLUDE_DIR issue is reported as CONC-291