Bug 1045013 - Changed symbol versions in libmysqlclient.so break compatibility
Summary: Changed symbol versions in libmysqlclient.so break compatibility
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mariadb   
(Show other bugs)
Version: 7.0
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Honza Horak
QA Contact: Branislav Blaškovič
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-19 13:06 UTC by Norvald H. Ryeng
Modified: 2016-08-02 20:47 UTC (History)
9 users (show)

Fixed In Version: mariadb-5.5.34-5.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 13:11:53 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to provide dual symbol versions for libmysqlclient.so in 5.5 (23.59 KB, patch)
2014-01-10 15:03 UTC, Norvald H. Ryeng
no flags Details | Diff
Patch to provide dual symbol versions for libmysqlclient.so in 5.5 a bit adjusted for mariadb (22.76 KB, patch)
2014-01-15 06:26 UTC, Honza Horak
no flags Details | Diff

Description Norvald H. Ryeng 2013-12-19 13:06:54 UTC
Description of problem:

The libmysqlclient.so library in RHEL7 uses non-standard symbol
versions. In upstream 5.5 the symbols are unversioned due to a bug in
the build scripts. This has been fixed in the next major version and
symbols are versioned "libmysqlclient_18". In RHEL7, some symbols are
versioned "libmysqlclient_16" while other are versioned
"libmysqlclient_18".

Previous RHEL versions have provided standard (upstream) symbol
versions. This change breaks library compatibility for client
applications. It is no longer possible for users to:
 
 - build on RHEL7 and run on other Linux distros
 - build on other Linux distros and run on RHEL7
 - build on RHEL7 and use with client library from upstream
 - build with client library from upstream and run on RHEL7

In some cases these scenarios would work (depending on distro and
client library versions), but in the general case the library in RHEL7
is incompatible with upstream and other Linux distros. This change
affects users of MySQL, Percona and MariaDB.

Suggested fix:

Either deliver unversioned symbols or tag all symbols with the version
"libmysqlclient_18", as is done by upstream in later major releases.

Version-Release number of selected component (if applicable):

5.5 / libmysqlclient.so.18

How reproducible:

Always.

Steps to Reproduce:

1. objdump -T /usr/lib64/mysql/libmysqlclient.so.18

Actual results:

Some symbols are versioned "libmysqlclient_16".

Expected results:

No symbols versioned "libmysqlclient_16".

Additional info:

Comment 6 Honza Horak 2014-01-03 15:01:17 UTC
(In reply to Norvald H. Ryeng from comment #0)
> The libmysqlclient.so library in RHEL7 uses non-standard symbol
> versions. In upstream 5.5 the symbols are unversioned due to a bug in
> the build scripts. This has been fixed in the next major version and
> symbols are versioned "libmysqlclient_18". In RHEL7, some symbols are
> versioned "libmysqlclient_16" while other are versioned
> "libmysqlclient_18".

Hi Norvald, when comparing libmysqlclient.so symbols in our and MariaDB upstream's builds (done by building with and without our downstream changes), I indeed see some differences, but only in symbols versioned libmysqlclient_18_mariadb; not in symbols versioned libmysqlclient_16 vs. libmysqlclient_18 (except some symbols more in MariaDB upstream).

Can you be more specific, please, which symbols versioned as libmysqlclient_16 do you consider to be a problem/different from MariaDB upstream? (maybe you meant Oracle's MySQL as upstream?)

> Suggested fix:
> 
> Either deliver unversioned symbols or tag all symbols with the version
> "libmysqlclient_18", as is done by upstream in later major releases.

As I see, MariaDB upstream actually uses both, libmysqlclient_16 and libmysqlclient_18 versions -- just checking the current code:
http://bazaar.launchpad.net/~maria-captains/maria/5.5/view/head:/libmysql/libmysql_rpm_version.in
http://bazaar.launchpad.net/~maria-captains/maria/10.0/view/head:/libmysql/libmysql_rpm_version.in

Comment 8 Norvald H. Ryeng 2014-01-06 13:28:53 UTC
(In reply to Honza Horak from comment #6)
> (In reply to Norvald H. Ryeng from comment #0)
> > The libmysqlclient.so library in RHEL7 uses non-standard symbol
> > versions. In upstream 5.5 the symbols are unversioned due to a bug in
> > the build scripts. This has been fixed in the next major version and
> > symbols are versioned "libmysqlclient_18". In RHEL7, some symbols are
> > versioned "libmysqlclient_16" while other are versioned
> > "libmysqlclient_18".
> 
> Hi Norvald, when comparing libmysqlclient.so symbols in our and MariaDB
> upstream's builds (done by building with and without our downstream
> changes), I indeed see some differences, but only in symbols versioned
> libmysqlclient_18_mariadb; not in symbols versioned libmysqlclient_16 vs.
> libmysqlclient_18 (except some symbols more in MariaDB upstream).

How did you build the upstream library? IIUC, MariaDB uses different
symbol versions in their RPM packages than in other packages. When you
build the library yourself, the default is unversioned symbols, but if
you choose to build an RPM package, you'll get Fedora symbol
versions. I think this behavior was introduced in an attempt to fit
into Fedora: https://mariadb.atlassian.net/browse/MDEV-3923

Unfortunately, the result is that the client library is incompatible
with itself in different packaging formats. What is done in Fedora is
done, and it will take some time to undo it, but I'm hoping RHEL7 will
not adopt this practice but instead follow upstream versioning closer.

> 
> Can you be more specific, please, which symbols versioned as
> libmysqlclient_16 do you consider to be a problem/different from MariaDB
> upstream? (maybe you meant Oracle's MySQL as upstream?)

All symbols that are versioned libmysqlclient_16.

MariaDB has done the above change to the library when building for RPM
packages only. MySQL and Percona have not adopted these changes.

> 
> > Suggested fix:
> > 
> > Either deliver unversioned symbols or tag all symbols with the version
> > "libmysqlclient_18", as is done by upstream in later major releases.
> 
> As I see, MariaDB upstream actually uses both, libmysqlclient_16 and
> libmysqlclient_18 versions -- just checking the current code:
> http://bazaar.launchpad.net/~maria-captains/maria/5.5/view/head:/libmysql/
> libmysql_rpm_version.in
> http://bazaar.launchpad.net/~maria-captains/maria/10.0/view/head:/libmysql/
> libmysql_rpm_version.in

But not in
http://bazaar.launchpad.net/~maria-captains/maria/5.5/view/head:/libmysql/libmysql.ver.in,
which is used when building deb packages. If you just build the
binaries, they don't use any of these files, and the symbols are
unversioned.

In MySQL and Percona, the symbols are unversioned in 5.5 and
libmysqlclient_18 in 5.6 (using the libmysql.ver.in file).

Comment 10 Honza Horak 2014-01-09 13:53:21 UTC
(In reply to Norvald H. Ryeng from comment #0)
> The libmysqlclient.so library in RHEL7 uses non-standard symbol
> versions. In upstream 5.5 the symbols are unversioned due to a bug in
> the build scripts. This has been fixed in the next major version and
> symbols are versioned "libmysqlclient_18". In RHEL7, some symbols are
> versioned "libmysqlclient_16" while other are versioned
> "libmysqlclient_18".

I talked to MariaDB upstream and they're willing to change versioning in their RPMs in case Fedora/RHEL-7 does it, so we're basically open to sync.

However, I'd like to do a step back and find the best solution here, not just blindly accept what MySQL will do.

Norvald, you writes that MySQL upstream is going to use only libmysqlclient_18 version. Is there a public bug report for that? I suppose we're talking about next 5.5.x release, since 5.6.x already uses libmysqlclient_18 version for all symbols. Doing so for 5.5.x would be a non-compatible change for everyone, who uses libmysqlclient_16 version now, not only Fedora but MariaDB upstream as well. What is the reason for using just libmysqlclient_18?

I mean the correct way is actually to have symbols versioned either libmysqlclient_16 or libmysqlclient_18 as Fedora/RHEL-7 does it. That's actually what Sergei from MariaDB upstream thinks as well:
https://lists.launchpad.net/maria-developers/msg06647.html

So Norwald, would MySQL upstream be able to adopt such versioning for next 5.5.x, instead introducing another incompatibility in all RPM packages?

There is also another way that Sergei suggested, which is using both versions for the older subset of the symbols, while setting libmysqlclient_18 as the default version for them. I've tried that and it seems to work fine in all use cases you mentioned above. Will at least this be acceptable for MySQL upstream?

Comment 11 Norvald H. Ryeng 2014-01-09 15:18:25 UTC
(In reply to Honza Horak from comment #10)
> (In reply to Norvald H. Ryeng from comment #0)
> > The libmysqlclient.so library in RHEL7 uses non-standard symbol
> > versions. In upstream 5.5 the symbols are unversioned due to a bug in
> > the build scripts. This has been fixed in the next major version and
> > symbols are versioned "libmysqlclient_18". In RHEL7, some symbols are
> > versioned "libmysqlclient_16" while other are versioned
> > "libmysqlclient_18".
> 
> I talked to MariaDB upstream and they're willing to change versioning in
> their RPMs in case Fedora/RHEL-7 does it, so we're basically open to sync.
> 
> However, I'd like to do a step back and find the best solution here, not
> just blindly accept what MySQL will do.

Very good, I'd really like this to be resolved too.

> Norvald, you writes that MySQL upstream is going to use only
> libmysqlclient_18 version. Is there a public bug report for that? I suppose

http://bugs.mysql.com/bug.php?id=64386

That bug was reported against 5.5, but we fixed it only in 5.6 because of the following reason: Applications linked with the new (versioned) library wouldn't be able to run with an old (unversioned) library. This was considered an incompatible change that we couldn't force on our users.

> we're talking about next 5.5.x release, since 5.6.x already uses
> libmysqlclient_18 version for all symbols. Doing so for 5.5.x would be a
> non-compatible change for everyone, who uses libmysqlclient_16 version now,
> not only Fedora but MariaDB upstream as well. What is the reason for using
> just libmysqlclient_18?

This is the way MySQL traditionally has done it. Symbol versions are the same as the library version. The fix we did for the above bug was actually just to enable the version script that was already in the source tree, which by accident had been disabled in the transition from automake to cmake.

MariaDB upstream only uses the mixed 16/18 versioning for RPMs. Any other build uses either unversioned symbols or 18. Since the library version was bumped in 5.5, there is no reason to use anything else than libmysqlclient_18. I'll explain more below.

> I mean the correct way is actually to have symbols versioned either
> libmysqlclient_16 or libmysqlclient_18 as Fedora/RHEL-7 does it. That's
> actually what Sergei from MariaDB upstream thinks as well:
> https://lists.launchpad.net/maria-developers/msg06647.html

Even if you keep libmysqlclient_16 symbols, an application compiled against libmysqlclient.so.16 will not be able to use libmysqlclient.so.18 because the soname is different. When the major library version number is bumped, there is no advantage in keeping old symbol versions.

So neither keeping the old version or bumping to a new version is more "correct" than the other. It's just a choice, and we followed the traditional way for this library, which is to bump the symbol version.

> So Norwald, would MySQL upstream be able to adopt such versioning for next
> 5.5.x, instead introducing another incompatibility in all RPM packages?

I'm afraid not. We won't do anything to 5.5 for the reason mentioned above. We made a mistake and we'll have to live with that as long as 5.5 is supported. I'm just hoping we can get out of this mess with future versions, and since you're going from libmysqlclient.so.16 to libmysqlclient.so.18 in RHEL7, now is the time to do it in RHEL. Otherwise, the problem could persist until we bump to version 19, which may be a long time.

> There is also another way that Sergei suggested, which is using both
> versions for the older subset of the symbols, while setting
> libmysqlclient_18 as the default version for them. I've tried that and it
> seems to work fine in all use cases you mentioned above. Will at least this
> be acceptable for MySQL upstream?

I like that solution.

Actually, we already do this in our own Fedora repository: http://bazaar.launchpad.net/~mysql/mysql-server/5.6/view/head:/packaging/rpm-fedora/mysql-5.6-libmysqlclient-symbols.patch

The patch is for 5.6, but we can backport to 5.5 if you wish.

The patch keeps the libmysqlclient_18 symbols as default and adds libmysqlclient_16 symbols, which means that old applications will continue to work while new applications that are compiled will contain libmysqlclient_18 symbols. It seems to work. And we're already maintaining this patch since we need it to fit into Fedora.

So if you apply this patch, applications that used to run on older RHEL will continue to run on RHEL7, and we establish a unified symbol versioning for the future. Does that sound like a good plan?

Comment 12 Honza Horak 2014-01-09 17:57:20 UTC
(In reply to Norvald H. Ryeng from comment #11)
> That bug was reported against 5.5, but we fixed it only in 5.6 because of
> the following reason: Applications linked with the new (versioned) library
> wouldn't be able to run with an old (unversioned) library. This was
> considered an incompatible change that we couldn't force on our users.

At least in Fedora it does run, but a warning is printed. But I still expect it is a no-go for MySQL upstream.

> So if you apply this patch, applications that used to run on older RHEL will
> continue to run on RHEL7, and we establish a unified symbol versioning for
> the future. Does that sound like a good plan?

Probably. Re-thinking all the possible solutions available right now this one seems like the least bad one. So let me summarize how it could look like:
* Fedora 20- and MariaDB RPMs for Fedora 20- would use what they use now -- both versions, no multiple versions for symbols
* RHEL-7, Fedora 21+ and MariaDB RPMs for Fedora 21+ would use both versions, where libmysqlclient_18 is default (back-port patch from MySQL Fedora builds)
* MySQL upstream 5.6 and Ubuntu/Debian would keep using only libmysqlclient_18 or would adopt the above
* MySQL upstream 5.5 would use no versioning

Then the incompatible libraries (from build-on-A-and-run-on-B point of view) will be these:
* built on Fedora20- or MariaDB RPMs for Fedora 20- and run on the rest (problem exists only until Fedora 20 retires)
* built on any other than MySQL upstream 5.5, Fedora20- or MariaDB RPMs for Fedora 20- and run on Fedora20- or MariaDB RPMs for Fedora 20- (problem exists only until Fedora 20 retires)
* built on any other than MySQL upstream 5.5 and run on MySQL upstream 5.5
The rest should be working fine (problem exists until MySQL 5.5 retires)

Is there something I don't see or what can be done better?

Comment 13 Norvald H. Ryeng 2014-01-10 15:03:37 UTC
Created attachment 848237 [details]
Patch to provide dual symbol versions for libmysqlclient.so in 5.5

A patch for MySQL 5.5 that

1) adds libmysqlclient_16 symbols and Fedora's renamed symbols
2) builds a shared embedded server (libmysqld.so.18.0.0)

Comment 14 Norvald H. Ryeng 2014-01-10 15:09:00 UTC
(In reply to Honza Horak from comment #12)
> (In reply to Norvald H. Ryeng from comment #11)
> > So if you apply this patch, applications that used to run on older RHEL will
> > continue to run on RHEL7, and we establish a unified symbol versioning for
> > the future. Does that sound like a good plan?
> 
> Probably. Re-thinking all the possible solutions available right now this
> one seems like the least bad one. So let me summarize how it could look like:
> * Fedora 20- and MariaDB RPMs for Fedora 20- would use what they use now --
> both versions, no multiple versions for symbols
> * RHEL-7, Fedora 21+ and MariaDB RPMs for Fedora 21+ would use both
> versions, where libmysqlclient_18 is default (back-port patch from MySQL
> Fedora builds)
> * MySQL upstream 5.6 and Ubuntu/Debian would keep using only
> libmysqlclient_18 or would adopt the above
> * MySQL upstream 5.5 would use no versioning
> 
> Then the incompatible libraries (from build-on-A-and-run-on-B point of view)
> will be these:
> * built on Fedora20- or MariaDB RPMs for Fedora 20- and run on the rest
> (problem exists only until Fedora 20 retires)
> * built on any other than MySQL upstream 5.5, Fedora20- or MariaDB RPMs for
> Fedora 20- and run on Fedora20- or MariaDB RPMs for Fedora 20- (problem
> exists only until Fedora 20 retires)
> * built on any other than MySQL upstream 5.5 and run on MySQL upstream 5.5
> The rest should be working fine (problem exists until MySQL 5.5 retires)
> 
> Is there something I don't see or what can be done better?

It looks good. I don't see a better solution at the moment.

See the attached patch for 5.5. It may not fit your needs perfectly, but it should be a good start. I also enabled building a shared embedded server since Fedora has that (we don't have it upstream). Just remove the patch for libmysqld/CMakeLists.txt to disable it.

Comment 15 Honza Horak 2014-01-10 16:50:43 UTC
> See the attached patch for 5.5. It may not fit your needs perfectly, but it
> should be a good start. I also enabled building a shared embedded server
> since Fedora has that (we don't have it upstream). Just remove the patch for
> libmysqld/CMakeLists.txt to disable it.

Thanks for the patch.

Comment 19 Honza Horak 2014-01-15 06:26:38 UTC
Created attachment 850341 [details]
Patch to provide dual symbol versions for libmysqlclient.so in 5.5 a bit adjusted for mariadb

Comment 22 Branislav Blaškovič 2014-03-18 11:42:40 UTC
If I understand it correctly, all libmysqlclient_16 symbols should have it's libmysqlclient_18 variant. Is it correct?

If yes, here is a test:

# rpm -q mariadb-libs
mariadb-libs-5.5.35-3.el7.x86_64


:: [   LOG    ] :: Make list of libmysqlclient_16
:: [   PASS   ] :: Running 'objdump -T /usr/lib64/mysql/libmysqlclient.so.18 | grep 'libmysqlclient_16' | grep '.text' | awk '{print $7}' > v16.dump' (Expected 0, got 0)
:: [   LOG    ] :: All v16 symbols should have it's v18 variant
:: [   PASS   ] :: Looking for 'mysql_hex_string' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_error' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_embedded' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_more_results' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_affected_rows' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_set_character_set' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_fetch_row' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_bind_param' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_param_count' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_ping' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_set_local_infile_handler' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_dump_debug_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_fetch_field' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_affected_rows' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'free_defaults' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_field_tell' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_close' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_insert_id' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_server_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_param_metadata' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_thread_init' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_fetch_field_direct' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_errno' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_autocommit' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_list_tables' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_select_db' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_send_long_data' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_set_server_option' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_server_end' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_data_seek' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_attr_set' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_list_processes' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'my_print_help' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_fetch_lengths' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_prepare' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_fetch_column' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'handle_options' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_error' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_thread_safe' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_client_version' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_num_rows' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_row_seek' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_send_query' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_row_tell' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_warning_count' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_change_user' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_ssl_set' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_client_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_options' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_store_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_list_dbs' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_character_set_name' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_sqlstate' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_execute' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_ssl_cipher' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_parameters' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_num_fields' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_thread_id' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_bind_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_free_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_reset' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'load_defaults' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_field_count' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_real_query' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_attr_get' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_field_seek' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'my_init' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_init' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_store_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_server_init' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_free_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_set_local_infile_default' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_kill' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_field_count' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_proto_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_shutdown' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_result_metadata' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_refresh' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_fetch_fields' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_next_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_eof' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'myodbc_remove_escape' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_init' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'my_make_scrambled_password' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_rollback' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_use_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_close' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_insert_id' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_list_fields' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_character_set_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_host_info' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_sqlstate' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_get_server_version' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_real_connect' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_num_rows' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_row_seek' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_errno' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_data_seek' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_row_tell' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_debug' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stmt_fetch' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_read_query_result' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_real_escape_string' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_commit' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_escape_string' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_stat' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_query' as libmysqlclient_18 (Expected 0, got 0)
:: [   PASS   ] :: Looking for 'mysql_thread_end' as libmysqlclient_18 (Expected 0, got 0)
:: [   LOG    ] :: Duration: 8s
:: [   LOG    ] :: Assertions: 110 good, 0 bad
:: [   PASS   ] :: RESULT: Test

Comment 23 Honza Horak 2014-03-24 15:12:24 UTC
(In reply to Branislav Blaškovič from comment #22)
> If I understand it correctly, all libmysqlclient_16 symbols should have it's
> libmysqlclient_18 variant. Is it correct?

Yes.

> If yes, here is a test:

The test seems fine to me.

Comment 24 Branislav Blaškovič 2014-03-31 11:23:17 UTC
Beaker job: https://beaker.engineering.redhat.com/jobs/619753

Comment 25 Ludek Smid 2014-06-13 13:11:53 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.