maria-developers team mailing list archive
Mailing list archive
Re: MariaDB connectors - dynamic libraries for Fedora (and all OSs that forks from it)
On 27.10.2016 11:22, Michal Schorm wrote:
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
In that moment, it uses stuff from library of connector C, but
connector C library seems to keep its secrets to itself - concretely
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
about that. We will add option to dynamically link against Connector/C
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.
Are there any reasons to not support dynamic libraries?
What could be the best solution from your point of view?
Core Services - Databases Team
mail: mschorm@xxxxxxxxxx <mailto:mschorm@xxxxxxxxxx>
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