Bug 736748 - MySQL C API missing handle_options and get_tty_password functions
Summary: MySQL C API missing handle_options and get_tty_password functions
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tom Lane
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-08 15:34 UTC by Curtis J Blank
Modified: 2013-07-03 03:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-08-07 18:58:20 UTC

Attachments (Terms of Use)

Description Curtis J Blank 2011-09-08 15:34:44 UTC
Description of problem:

MySQL 5.5 is missing handle_options and get_tty_password functions.

Pulled the MySQL 5.5.15 source code and these functions are still in the source.

openSuSE 11.4, RedHat EL 6.1, Ubuntu 11.04 have them, FC15 does not. Can't
compile and link an application that uses them

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

MySQL 5.5

How reproducible:


Steps to Reproduce:
1. Try to make the application
Actual results:

Lind fails, can't resolve handle_options and get_tty_password.

Expected results:

Expect the application to compile and link correctly.

Additional info:

Comment 1 Tom Lane 2011-09-08 15:49:52 UTC
Those have never been part of the documented API for MySQL --- or can you show me otherwise?  As of F15 we are deliberately hiding symbols that were not meant to be exported from libmysqlclient.

Comment 2 Curtis J Blank 2011-09-08 16:19:23 UTC
Thanks for the quick reply.

Yeah you're technically correct, but it's kind of interesting you say that because just this year it appears you put them back in.


Well at least handle_options. And I do agree that the fact they are documented in Paul DuBois's book is a pretty good case for them. 

What's the downside? As long as MySQL provides and supports them I really don't see any issue. When/If they were to pull them then well, done deal.

Comment 3 Tom Lane 2011-09-08 18:52:33 UTC
Hm, sorry, should have checked the code before replying.  Yes, handle_options is part of the de facto API, but get_tty_password isn't.  Are you sure you're having trouble linking to the former?  If so I need a test case.

Comment 4 Curtis J Blank 2011-09-08 19:05:20 UTC
Source code is here:


Got this from a user:

But FC15 which has MySQL 5.5:

[root@northnarra vproweather-1.0.2]# rpm -qa | grep mysql
[root@northnarra vproweather-1.0.2]#


gcc -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm main.o dhandler.o mySQLhandler.o -o vproweather
main.o: In function `main':
/home/reubenf/vproweather-1.0.2/main.c:538: undefined reference to `my_progname'
/home/reubenf/vproweather-1.0.2/main.c:546: undefined reference to `handle_options'
main.o: In function `GetParms':
/home/reubenf/vproweather-1.0.2/main.c:1689: undefined reference to `get_tty_password'
collect2: ld returned 1 exit status
make: *** [vproweather] Error 1
[root@northnarra vproweather-1.0.2]#

These are all the standard FC15 RPMs too, not from any 3rd party repository or anything..

Comment 5 Tom Lane 2011-09-08 23:20:18 UTC
Interesting.  The answer is that handle_options is in fact not in the library in 5.5, because upstream failed to include it when they moved over to a cmake-based build system.

It's not clear to me whether that's intentional or not, so I've filed a request for clarification here:

If they respond that they intend to support it going forward, I'll be happy to patch things so it shows up again ... but if the official position is that you should never have relied on it, well, you should never have relied on it.  I leave you to draw your own conclusions about relying on get_tty_password.

Comment 6 Curtis J Blank 2011-09-09 12:50:31 UTC
I understand but it's not efficient IMO for people to have to code their own functions to replicate handle_options and get_tty_password when there are perfectly good ones supplied by a vendor but they're hidden by the distros. That's what I'll land up doing to get around this if need be. And like I said, you and gentoo are hiding them, Ubuntu, openSuSE, and even RedHat EL supplies them currently. To have them then all of a sudden decide to hide them kinda boggles my mind... Like I said, if MySQL decided to deprecate them, well, they own them, but for a distro to make the decision?

Comment 7 Tom Lane 2011-09-09 15:29:45 UTC
I think you're blaming the messenger here.  On closer inspection, neither get_tty_password nor handle_options are present in the 5.5 version of the library at all.  It's not the Fedora symbol filter that created your problem; it's the fact that upstream wasn't concerned about continuing to export functions that aren't officially part of their API.

But the reason I put in that symbol filter is that unmodified, libmysqlclient is a complete disaster from the standpoint of polluting application global namespace.  It defines something upward of a thousand symbols, more than half of which don't even start with "my".  I thought it was essential to make it a bit cleaner and get it down to just exporting the actually intended-to-be-visible symbols, in order to prevent unforeseen conflicts.

Comment 8 Curtis J Blank 2011-10-17 00:19:00 UTC
Ok, I wrote out handle_options and get_tty_password now when people compile on Fedora they get this:

/main.c:540: undefined reference to `my_progname'

my_progname is defined in my_sys.h and used by the macro MY_INIT.

So how come my_progname is not in Fedora but is in all the other distros?

Comment 9 Curtis J Blank 2011-10-17 00:27:03 UTC
And if you're stripping out my_progname how does that then affect error reporting because that is the purpose for it being there?

Comment 10 Tom Lane 2011-10-17 00:35:10 UTC
I don't see my_progname, nor MY_INIT, anywhere in the published API specification for libmysqlclient.  I'm trying to keep what the library exports down to just the published API symbols, because anything else could disappear at any instant.  Which is in fact exactly what happened to handle_options and get_tty_password.

I'm aware that the mysql docs recommend #include'ing some headers that define a great deal more stuff than what they document.  I don't think that that means you should rely on that other stuff and expect that it will never break for you.

Comment 11 Tom Lane 2011-10-17 00:46:45 UTC
(In reply to comment #10)
> I don't see my_progname, nor MY_INIT, anywhere in the published API
> specification for libmysqlclient.

,,, but having said that, some digging in the code reveals that handle_options assumes its callers will set my_progname, so if we continue to export handle_options then we should also export my_progname.  Right now that's a moot point since upstream has removed handle_options from the library altogether.  I'm still waiting for some response to that upstream bug report :-(

Comment 12 Curtis J Blank 2011-10-17 01:14:38 UTC
I just compiled 5.5.15 from the tarball and my_progname is included but it appears handle_options and get_tty_password are not. Maybe it's a build option to include handle_options and get_tty_password but that's a moot point because I'm not going to use something that is not in by their default.

And the Fedora version in question has MySQL 5.5.14

So like I said if MySQL chooses to remove things that is their prerogative because they own it and when that occurs us programmers will have to deal with it but IMO the distros shouldn't take it upon themselves to do that.  

And looking through the 5.5.15 source code there's 139 instances in 24 functions where my_progname is used.

Comment 13 Curtis J Blank 2011-10-17 01:53:48 UTC
I just pulled down and compiled 5.5.16 from the tarball which is the latest available from MySQL and my_progname is included in it too.

Comment 14 Fedora End Of Life 2012-08-07 18:58:23 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:

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