Bug 736748
Summary: | MySQL C API missing handle_options and get_tty_password functions | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Curtis J Blank <Curt.Blank> |
Component: | mysql | Assignee: | Tom Lane <tgl> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | Curt.Blank, hhorak, reuben-redhatbugzilla, tgl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-08-07 18:58:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Curtis J Blank
2011-09-08 15:34:44 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. 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. http://lists.fedoraproject.org/pipermail/scm-commits/2011-January/538847.html 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. 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. Source code is here: http://www.curtronics.com/Weather/ftp/vproweather-1.0.3.tar.gz Got this from a user: But FC15 which has MySQL 5.5: [root@northnarra vproweather-1.0.2]# rpm -qa | grep mysql nagios-plugins-mysql-1.4.15-4.fc15.x86_64 mysql-server-5.5.14-2.fc15.x86_64 mysql-5.5.14-2.fc15.x86_64 php-mysql-5.3.6-2.fc15.x86_64 mysql-devel-5.5.14-2.fc15.x86_64 mysql-libs-5.5.14-2.fc15.x86_64 [root@northnarra vproweather-1.0.2]# fails: 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.. 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: http://bugs.mysql.com/bug.php?id=62394 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. 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? 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. 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? And if you're stripping out my_progname how does that then affect error reporting because that is the purpose for it being there? 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. (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 :-( 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. 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. 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |