Bug 1045013
Summary: | Changed symbol versions in libmysqlclient.so break compatibility | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Norvald H. Ryeng <norvald.ryeng> | ||||||
Component: | mariadb | Assignee: | Honza Horak <hhorak> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Branislav Blaškovič <bblaskov> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 7.0 | CC: | bblaskov, databases-maint, jscotka, norvald.ryeng, riehecky, rvokal, vpavlin, vuvova, yngve.svendsen | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
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: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Norvald H. Ryeng
2013-12-19 13:06:54 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 (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). (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? (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? (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? 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)
(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. > 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.
Created attachment 850341 [details]
Patch to provide dual symbol versions for libmysqlclient.so in 5.5 a bit adjusted for mariadb
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 (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. 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. |