Debian GNU/Linux 9 (testing)
MariaDB 10.1.23
MariaDB Connector/C 2.3.2

Similar error was fixed in ZBX-11335.

I think - better get rid of this guessing library name at all.

Thanks, Andrey, for contribution

Updated patch - new mariadb package carry mariadb_config instead of mysql_config so check it too.

This doesn't really work right. It assumes the last item in the output of mysql_config is the mysql/mariadb library, but this is not always the case, viz on Fedora Rawhide:

<mock-chroot> sh-4.4# mysql_config --libs
-L/usr/lib64/mysql -lmariadb -lpthread -lz -ldl -lm -lssl -lcrypto

so it winds up with `MYSQL_LIBS` as `-lcrypto`, and of course compilation fails.

Why are you doing all this splitting up and parsing and checking of the `mysql_config` output at all? Why not just trust the values it provides and use them unaltered? Even when this 'works', it will throw away `-lz -lpthread -ldl -lm -lssl -lcrypto` and only take `-lmariadb`, which doesn't seem right.

Oh, I see. This is trying to avoid overlinking. But yes, it doesn't really work right...

v3 patch.
Properly check presence mysql_error() in each lib reported by mysql_config or mariadb_config

Here's an alternative patch; this works at least for me, with the recent MariaDB 10.2 with `-lmariadb`.

Attached right patch for now

Isn't the static branch in your v3 patch wrong? I think you meant to use a different variable than _client_lib_name there, presumably _full_libmysql_libs ?

Well, the patch has other problems, too. The new AC_CHECK_LIB test won't work properly in all cases, because it doesn't use the correct LDFLAGS (so on Fedora, where libmariadb is in /usr/lib/mariadb , the test fails even for `-lmariadb`, because it can't find it). And there's at least one other reason why your version can't possibly wind up setting the correct libs for a static compile...

Provide full output of `mysql_config`.

Static link with mysql is a pain. It's possible to write correct m4 for all variants but it take some time.

Here's my latest effort at a patch, which I think should handle things better. I certainly can't test all cases here, though, all I can say for sure is this builds successfully non-statically with MariaDB 10.2 on Fedora Rawhide. Haven't tried building against older MariaDB or MySQL or building statically.

The `mysql_config` output on Fedora Rawhide looks like this:

<mock-chroot> sh-4.4# mysql_config
Usage: /usr/bin/mysql_config-64 [OPTIONS]
Options:
        --cflags         [-I/usr/include/mysql ]
        --include        [-I/usr/include/mysql]
        --libs           [-L/usr/lib64/mysql  -lmariadb -lpthread -lz -ldl -lm -lssl -lcrypto]
        --libs_r         [-L/usr/lib64/mysql  -lmariadb -lpthread -lz -ldl -lm -lssl -lcrypto]
        --plugindir      [/usr/lib64/mysql/plugin]
        --socket         [/var/lib/mysql/mysql.sock]
        --port           [0]
        --version        [10.2.7]
        --libmysqld-libs [-L/usr/lib64/mysql  -lmysqld -lpthread -lz -lm -ldl -lssl -lcrypto -lpcre -lcrypt -laio -lsystemd]
        --variable=VAR   VAR is one of:
                pkgincludedir [/usr/include/mysql]
                pkglibdir     [/usr/lib64/mysql]
                plugindir     [/usr/lib64/mysql/plugin]

So, with your patch, think what happens in that first loop through $_full_libmysql_libs . The first thing we see is -L/usr/lib64/mysql , which is duly appended to MYSQL_LDFLAGS , okay. But we're not actually using the contents of MYSQL_LDFLAGS as our LDFLAGS value as we iterate through the loop; we only backup LDFLAGS and do:

LDFLAGS="${LDFLAGS} ${MYSQL_LDFLAGS}"

AFTER this loop is complete. So next in the loop we see -lmariadb , and the loop tries to do AC_CHECK_LIB(mariadb, mysql_error) - but that will fail, even though it should succeed, because we haven't updated LDFLAGS yet, so that compile check will not use `-L/usr/lib64/mysql` and so will not be able to find the library.

Your variant is much better. I'm slightly update it to reflect our mariadb packages configuration.

Also, I'm use debian packages from mariadb.org and with it is impossible to compile zabbix in static variant with mariadb.

Thanks.

BTW, it'd sure be nice if you folks could decide on spaces or tabs for that file.

I've tried this patch in FreeBSD, but still not finding mysqlclient library.
Any idea?

[...]
checking size of void *... 8
checking for mysql_config... /usr/local/bin/mysql_config
checking for main in -l... no
configure: error: Not found mysqlclient library

$ mysql_config --libs
-L/usr/local/lib/mysql  -lmariadb -pthread -lz -lpthread -lm -liconv -lssl -lcrypto -L/usr/local/lib

$ mysql_config
Usage: /usr/local/bin/mysql_config [OPTIONS]
Options:
        --cflags         [-I/usr/local/include/mysql -I/usr/local/include/mysql/.. ]
        --include        [-I/usr/local/include/mysql -I/usr/local/include/mysql/..]
        --libs           [-L/usr/local/lib/mysql  -lmariadb -pthread -lz -lpthread -lm -liconv -lssl -lcrypto -L/usr/local/lib ]
        --libs_r         [-L/usr/local/lib/mysql  -lmariadb -pthread -lz -lpthread -lm -liconv -lssl -lcrypto -L/usr/local/lib ]
        --plugindir      [/usr/local/lib/mysql/plugin]
        --socket         [/tmp/mysql.sock]
        --port           [0]
        --version        [10.2.7]
        --libmysqld-libs [-L/usr/local/lib/mysql  -lmysqld -L/usr/local/lib ]
        --variable=VAR   VAR is one of:
                pkgincludedir [/usr/local/include/mysql]
                pkglibdir     [/usr/local/lib/mysql]
                plugindir     [/usr/local/lib/mysql/plugin]

checking for main in -l... no

Patched version search mysql_error() function, your log show searching main() function. You don't run autoreconf after patch ?

I did not.
Now it worked, thanks!

checking for mysql_config... /usr/local/bin/mysql_config
checking for mysql_error in -lmariadb... yes
checking for mysql_error in -lz... no
checking for mysql_error in -lpthread... no
checking for mysql_error in -lm... no
checking for mysql_error in -liconv... no
checking for mysql_error in -lssl... no
checking for mysql_error in -lcrypto... no

I was unable to get it to work (FreeBSD 11.0, poudriere to build ports). Would you mind sharing the patch file you used to get this to work (preferably in FreeBSD ports patch format)?

Sure, it's here:
svn-patch-zabbix32-server-mariadb.patch
It will be nice if we get this fixed (here) in all versions.

@bdaio Thanks for that. I see that the autoreconf in the USES flag is the trick I needed.

Will you submit this patch to the port maintainer?

@bdaio Just a note that your patch didn't apply cleanly to zabbix32-server, but it did work just fine against zabbix34-server with a tweak to PORTREVISION. Perhaps that's enough anyway. We'll need something similar for zabbix34-proxy.

However when I try to run the patched zabbix server I get this error:

17858:20170904:121856.342 using configuration file: /usr/local/etc/zabbix34/zabbix_server.conf
 17858:20170904:121856.357 current database version (mandatory/optional): 03040000/03040000
 17858:20170904:121856.357 required mandatory version: 03040000
 17858:20170904:121856.764 Got signal [signal:11(SIGSEGV),reason:1,refaddr:0x0]. Crashing ...
 17858:20170904:121856.764 ====== Fatal information: ======
 17858:20170904:121856.764 program counter not available for this architecture
 17858:20170904:121856.764 === Registers: ===
 17858:20170904:121856.764 register dump not available for this architecture
 17858:20170904:121856.764 === Backtrace: ===
 17858:20170904:121856.764 9: 0x494c8b <zbx_set_common_signal_handlers+667> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.764 8: 0x803cf779d <pthread_sigmask+1293> at /lib/libthr.so.3
 17858:20170904:121856.765 7: 0x803cf6d6f <pthread_getspecific+3743> at /lib/libthr.so.3
 17858:20170904:121856.765 6: 0x7ffffffff003
 17858:20170904:121856.765 5: 0x488fff <zbx_dbsync_compare_action_ops+191> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.765 4: 0x474a8a <DCsync_configuration+14810> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.765 3: 0x4237fc <MAIN_ZABBIX_ENTRY+604> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.765 2: 0x493dc5 <daemon_start+437> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.765 1: 0x4234d7 <main+1255> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.765 0: 0x41b03f <_start+383> at /usr/local/sbin/zabbix_server
 17858:20170904:121856.765 === Memory map: ===
 17858:20170904:121856.765 memory map not available for this platform
 17858:20170904:121856.765 ================================

Well, strike that previous comment. Zabbix 3.4.1 just hit FreeBSD ports and that one fixes the problem above.

So, against 3.4.1, the patch worked perfectly other than the diff having an issue with the PORTREVISION line which is easily fixed. I've not got this running in production against MariaDB 10.2 on FreeBSD 11.0 collecting 36 values per second without any issue.

Fixed in svn://svn.zabbix.com/branches/dev/ZBX-12232

Simplified the checks for the mysql and mariadb libraries. Added
support for mariadb_config and removed extra code that is
completely unuseful for building.
The fix is not only for debian, but for all the platforms.

Remove Check if required version of MySQL is available code too - it never used.

And check mysql_error() function inside

AC_CHECK_LIB($_lib_name, main, [ .....

- library not contain main() function.

lynxchaus

To be fair, when I started to work on it, I suspected the majority
of the script is actually useless and could be just dumped
altogether.
However, before taking a decision like that, I wanted to make a
first step and simplify it.
The AC_CHECK_LIB you are referring to, was done exactly like
that even before and I left it for "compatibility", but I think that
if we want, we could rewrite the mysql check m4 script with a
much simplified version from scratch.

A note:

If you are installing the mariadb/c connector from source. it
will install, as usual, a dynamic linkable library and a statically
linkable one.
Curios enough is the fact that the procedure will install an so
object called libmariadb.so and a static library called
libmysqlclient.a.
This is NOT how generally things should be done. The accepted
convention is to call both the static and dynamic libraries with
the same name, and change only their extensions.
The linker will then find the right library automatically passing
the right -l flags.
Right now if you call mariadb_config, it will give you back the
wrong flags for static compilation of zabbix.
the workaround is to create a symlink to the libmysqlclient.a
library and call it libmariadb.a

-static ?? really??

Ok, if you want to compile zabbix statically:
1. adjust configure.ac to check lipthread/libz/liblzma first.
2. move *SSL checking procedures before checking mysql presence
3. push all found libraries at start (surprise-surprise, gcc linker want it in specific order)
4. realize this big mess and rewrite big half of m4/* to use PKG_CHECK_MODULES() instead of searching by hands for libraries/includes/etc.

And after that you hit the wall - openipmi|net-snmp|ssh2|curl libraries bundled with GnuTLS, GnuTLS itself want gmp, nettle, p11-kit. Debian/Ubuntu not ships libp11-kit.a.
Ok, disabled jabber/ipmi/ssh/curl/unixodbc/snmp support.

Successfully build server with mysql. But for what? ping, external scripts and nothing?

Forget about static linkning.

lynxchaus

Yes, I know what you mean

In theory we support building zabbix statically, but I think it's kinda broken.
I don't know if it make sense for us to even support the possibility at all
these days.

Released in:

• pre-3.0.14rc1 r74909
• pre-3.4.5rc1 r74910
• pre-4.0.0alpha1 (trunk) r74911

Err. Still checking main()..
$ objdump -Tt /usr/lib/libmariadbclient.so.18 | grep -c main
0

Did you read comments for this bug?

lynxchaus

Yes I read the comment, actually I kept the "wrong" behaviour on
purpose for now.
I'm working on opening a separated issue for reviewing, in general,
the m4 scripts we use for third party libraries and fix them.

Hi @Danilo,

svn-patch-zabbix32-server-mariadb.patch

I manually merged this patch to zabbix-3.4.7 and it worked.

This patch worked for me.

CentOS 7.3

MariaDB 10.1.33-1.el7.centos

pre-zabbix-3.4.11rc1-81960

The same symptoms