← Back to team overview

maria-developers team mailing list archive

Re: MariaDB connectors - dynamic libraries for Fedora (and all OSs that forks from it)


Hi Michal,

On 27.10.2016 11:22, Michal Schorm wrote:
Hello all,

I am new guy, who tries to add MariaDB connectors to Fedora. (And in the future, probabbly most of the MariaDB stuff will rest on me in Fedora)

So far I encountered one great issue.

In Fedora, we only use dynamic libraries (which makes, for example, maintaining different packages with same library much much easier).
But you guys, you don't seem like you are all for it.

Right now, I stopped at mariadb-connector-odbc package.
There is an issue, which makes it unusable when build as a dynamic library. In that moment, it uses stuff from library of connector C, but connector C library seems to keep its secrets to itself - concretely wrapper functions.

Here are impossible solutions:
* use static libraries in Fedora (can't - dynamic libys are one of the fundamental things in Fedora, same priority as use only FOSS) * link odbc connector towards mariadb-libs (can't - connectors are meant as replacement for mariadb-libs)

Here are some solutions that are at least not denied by deafult:
* start to support building all of your components as dynamic libraries (Best solution for us (for Fedora), because the closer to upstream code we are, the better. Needless to say, over 40 OSs forks somehow from Fedora)

You opened the issue https://jira.mariadb.org/projects/ODBC/issues/ODBC-55?filter=allissues about that. We will add option to dynamically link against Connector/C library
I only think that it will take some more than your proposed solution.

* export everything from C connector library (I assume, that is not what you want to do) * export just what is used by other components - mainly wrappers - some exaples for ODBC connector: my_no_flags_free, my_malloc, my_charset_utf8_general_ci, my_strndup, my_realloc, my_strdup, my_snprintf (Compromise for both sides, but can rise more issues later)

In C/C and C/ODBC 3.0 this problem has been tackled. C/C does not have those symbols any more, and C/ODBC uses malloc, strndup etc instead of those wrappers. Although my_charset_utf8_general_ci is renamed to ma_charset_utf8_general_ci and is still there. Not sure if it is exported, but it's also not a problem to stop using it in C/ODBC. In general I guess we do not use any functions beyond official API(or call them exported) in 3.0. If something is left, it will be fixed.

I hope that alleviates your concerns.

Best regards,

Are there any reasons to not support dynamic libraries?

What could be the best solution from your point of view?



Michal Schorm
Core Services - Databases Team
mail: mschorm@xxxxxxxxxx <mailto:mschorm@xxxxxxxxxx>
Brno-IRC: mschorm

Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp