Description of problem: fpcsrc (/usr/share/fpcsrc/packages/mysql is incorrect for mariadb usage Version-Release number of selected component (if applicable): 3.0.4-2 How reproducible: Any program (cqrlog) that uses fpcsrc/package/mysql breaks on attempting to dlopen the client library. Steps to Reproduce: 1. Build app/package such as cqrlog 2. Attempt to run 3. Connection object will throw an error: "Can not load default MySQL library ("libmysqlclient.so.18" or "libmysqlclient.so"). Check your installation." - This error is in cqrlog file dData.pas. Actual results: dlopen fails causing app to abort. Expected results: Library should load and the app continues. Additional info: See BZ #1592176 The offending code is in fpcsrc/package/mysql/mysql.inc: { This file is created by H2Pas, and thereafter heavily edited to make it readable and dynamically loadable. The goal was not to be complete, but to make it work and maintainable. The mysql_com.h, mysql.h and some other files are merged together into this one file. Automatically converted by H2Pas 1.0.0 from mysql_com.h / mysql.h The following command line parameters were used: -p -D -l mysqlclient mysql_com.h / mysql.h } {$MODE objfpc} {$MACRO on} interface {$ifdef Load_Dynamically}{$define LinkDynamically}{$endif} uses {$IFDEF LinkDynamically} sysutils, {$ENDIF} ctypes, dynlibs; {$IFDEF Unix} {$DEFINE extdecl:=cdecl} const mysqllib = 'libmysqlclient.'+sharedsuffix; {$IF DEFINED(mysql57)} mysqlvlib = mysqllib+'.20'; {$ELSEIF DEFINED(mysql55) or DEFINED(mysql56)} mysqlvlib = mysqllib+'.18'; {$ELSEIF DEFINED(mysql51)} mysqlvlib = mysqllib+'.16'; {$ELSEIF DEFINED(mysql50)} mysqlvlib = mysqllib+'.15'; {$ELSEIF DEFINED(mysql41)} mysqlvlib = mysqllib+'.14'; {$ELSE} mysqlvlib = mysqllib+'.12'; {$ENDIF} {$ENDIF} {$IFDEF Windows} {$DEFINE extdecl:=stdcall} const mysqllib = 'libmysql.dll'; mysqlvlib = 'libmysql.dll'; {$ENDIF} No, I don't have a solution for this. As noted in the comments at the top of the file, this is an incredibly bad idea in that intimate knowledge about other packages is buried deep. I'd rather see all this in the link step of a build (assuming the API hasn't morphed...)
I think the problem is that libmysqlclient is provided by mariaDB in its mariadb-connector-c-devel package and not in mariadb-connector-c: $ dnf repoquery -l mariadb-connector-c-devel | grep libmysqlclient /usr/lib/libmysqlclient.so /usr/lib/libmysqlclient_r.so /usr/lib64/libmysqlclient.so /usr/lib64/libmysqlclient_r.so /usr/lib64/libmysqlclient.so /usr/lib64/libmysqlclient_r.so /usr/lib/libmysqlclient.so /usr/lib/libmysqlclient_r.so $ dnf repoquery -l mariadb-connector-c | grep libmysqlclient <EMPTY RESPONSE> while community-mysql-libs provides it in its runtime package and not in devel: $ dnf repoquery -l community-mysql-libs | grep libmysqlclient /usr/lib/mysql/libmysqlclient.so.20 /usr/lib/mysql/libmysqlclient.so.20.3.8 /usr/lib/mysql/libmysqlclient.so.20 /usr/lib/mysql/libmysqlclient.so.20.3.10 /usr/lib64/mysql/libmysqlclient.so.20 /usr/lib64/mysql/libmysqlclient.so.20.3.8 /usr/lib64/mysql/libmysqlclient.so.20 /usr/lib64/mysql/libmysqlclient.so.20.3.10 $ dnf repoquery -l community-mysql-libs-devel | grep libmysqlclient <EMPTY RESPONSE> Maybe cqr should require community-mysql-libs at runtime instead of mariadb-connector-c-devel?
I'm unfamiliar with all of these packages mariadb<->mysql. Something has to give here. This is both a mix of mysql forks and bad packaging, in reverse image no less... If mariadb is the post-Larry E. future, it should conform to common package, package-devel practice and have the complete *.so mix in the package and the *.a and headers etc. in the -devel. And if mariadb is supposed to be a plug-and-play of "old" mysql, they shouldn't muck with the runtime footprint. Also, I see no reason to have a community-mysql unless there are unavoidable API legacy issues. I'm also unfamiliar with fpc and its ecosystem so I am unclear why this library must be dynamically loaded. But that is an upstream, not packaging issue. See BZ #1592176 for the related bug.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.