When building MySQLdb: "ImportError: No module named _mysql" This little error message plagued me for about 3 weeks. After reformatting my hard drive and re-installing Linux, Python, MySQL and MySQLdb, all from the source files, I finally found the solution (well, it worked for me) and am posting it for anyone else that runs into the same trouble. The good news (for you) is that all the re-installing isn't necessary. Note that this solution is for a problem I had in following the "How-To ZMySQLDA - from download to connection" step number four. ### SOLUTION (worked for me)### In order to fix the "ImportError: No module named _mysql" error: Ensure that there exists the /usr/lib/mysql folder containing the following files: libdbug.a libmysqlclient.a libmysqlclient.so.6 libmysys.a libheap.a libmysqlclient.la libmysqlclient.so.6.0.0 libnisam.a libmerge.a libmysqlclient.so libmystrings.a <Problem #1> I had to copy /user/local/lib/mysql to /usr/lib/mysql </Problem #1> To fix the "ImportError: libmysqlclient.so.6: cannot open shared object file: No such file or directory" error: Ensure that there exists the libmysqlclient.so.6 file in the /usr/lib folder. <Problem #2> The libmysqlclient.so.6 file was missing from the /usr/lib folder. I tried putting a link to the libmysqlclient.so.6 file in the /usr/lib folder and it didn't work. Next, I copied the libmysqlclient.so.6.0.0 file to the /usr/lib folder, renamed it to libmysqlclient.so.6 and that was enought to make the build.py script run all the way through. </Problem #2> To successfully complete the installation, I did the following: [root@frankenstein MySQLdb]# make install [root@frankenstein MySQLdb]# cp MySQLdb.py{,c,o} /usr/local/lib/python1.5/site-packages [root@frankenstein MySQLdb]# cp ZMySQLDA.patch /usr/local/Zope [root@frankenstein MySQLdb]# cd /usr/local/Zope [root@frankenstein Zope]# patch -p1<ZMySQLDA.patch patching file `lib/python/Products/ZMySQLDA/DA.py' patching file `lib/python/Products/ZMySQLDA/db.py' Hunk #1 succeeded at 103 with fuzz 2. ### Explanation (what I learned) ### First, here's the full error message: gcc -fpic -I/usr/include/mysql -g -O2 -I/usr/local/include/python1.5 -I/usr /local/include/python1.5 -DHAVE_CONFIG_H -c ./_mysqlmodule.c gcc -shared _mysqlmodule.o -L/usr/lib/mysql -lmysqlclient -o _mysqlmodule.so /usr/i386-linux/bin/ld: cannot open -lmysqlclient: No such file or directory make: *** [_mysqlmodule.so] Error 1 Traceback (innermost last): File "build.py", line 14, in ? import MySQLdb File "MySQLdb.py", line 19, in ? from _mysql import * ImportError: No module named _mysql I needed to understand what was happening, so here is what I learned in breaking this error message down: <First Command> gcc -fpic -I/usr/include/mysql -g -O2 -I/usr/local/include/python1.5 -I/usr /local/include/python1.5 -DHAVE_CONFIG_H -c ./_mysqlmodule.c This command is creating an object file (it will be called "_mysqlmodule.o" by default) from the "_mysqlmodule.c" file. -fpic = tells the compiler to created a shared library -fPIC = tells the compiler to create a dynamically linked shard library (not used here, but good to know) -c = Tells the compiler to compile only - doesn't create an executable -g = compile code for debugging (I don't know why we are putting the debug info in it.) -O2 = Tells the compiler to use the second level of optimization -I<path> = Defines path to the header files that are '#include'd in the C programming code files. </First Command> <Second Command> gcc -shared _mysqlmodule.o -L/usr/lib/mysql -lmysqlclient -o _mysqlmodule.so This command creates a shared library out of _mysqlmodule.o, called _mysqlmodule.so, and links it to /usr/lib/mysql/libmysqlclient.so" -shared = Tells the compiler to place the compiled files into a library -o<name> = tells the linker to build the '<name>' library -L<path> = adds <path> to the list of paths to search when looking for the library to be linked -l<name> = Name of the library to link to. Tells the linker to link the -o<name> program to the 'lib<name>.so' library file </Second Command> <First Error> /usr/i386-linux/bin/ld: cannot open -lmysqlclient: No such file or directory This error happened because the linker (the ld program) searched for the "libmysqlclient.so" file and couldn't find it. </First Error> <Second Error> make: *** [_mysqlmodule.so] Error 1 Traceback (innermost last): File "build.py", line 14, in ? import MySQLdb File "MySQLdb.py", line 19, in ? from _mysql import * ImportError: No module named _mysql This error happened because the first error caused a failure to create the "_mysqlmodule.so" file. The "_mysqlmodule.so" library file contains a module called _mysql. Because the library file wasn't there, neither was the _mysql module. </Second Error> Next I tried to run the build.py script and received the following error: <Third Error> Traceback (innermost last): File "build.py", line 14, in ? import MySQLdb File "MySQLdb.py", line 19, in ? from _mysql import * ImportError: libmysqlclient.so.6: cannot open shared object file: No such file or directory This error happened because the "from _mysql import *" statement caused the "_mysqlmodule.so" library to be loaded, which caused the "libmysqlclient.so.6" to be loaded, also. Remember that the command: "gcc -shared _mysqlmodule.o -L/usr/lib/mysql -lmysqlclient -o _mysqlmodule.so" (the Second Command, above) linked the "libmysqlclient.so.6" library to the "_mysqlmodule.so" that's why they are both being loaded. </Third Error> I realize that this problem was likely caused by a missing, or incorrect, path statement somewhere in my system. My solution of simply copying files around is not very elegant, but it worked. A better solution would've been to fix the paths. I don't know how to do that, but when I figure that out, I'll come back and fix it. Any comments on this solution are welcomed! Eric.
Ensure that there exists the /usr/lib/mysql folder containing the following files: libdbug.a libmysqlclient.a libmysqlclient.so.6 libmysys.a libheap.a libmysqlclient.la libmysqlclient.so.6.0.0 libnisam.a libmerge.a libmysqlclient.so libmystrings.a
<Problem #1> I had to copy /user/local/lib/mysql to /usr/lib/mysql </Problem #1>
All this evil happened, because /usr/local/lib was not registered with your linker (ld) To do that go to '/etc/ld.so.conf' and add the library directory, like: /usr/local/lib Then simply run ldconfig Voila, all your problems should be gone. Regards, Stephan -- Stephan Richter - (901) 573-3308 - srichter@cbu.edu CBU - Physics & Chemistry; Framework Web - Web Design & Development PGP Key: 735E C61E 5C64 F430 4F9C 798E DCA2 07E3 E42B 5391
[Eric L. Walstad, on Fri, 31 Mar 2000] :: When building MySQLdb: :: "ImportError: No module named _mysql" :: :: This little error message plagued me for about 3 weeks. After reformatting :: my hard drive and re-installing Linux, Python, MySQL and MySQLdb, all from :: the source files, I finally found the solution (well, it worked for me) and :: am posting it for anyone else that runs into the same trouble. The good :: news (for you) is that all the re-installing isn't necessary. <snip rest of hair raising saga> Damn. What a nightmare. Eric, I'm going to make some assumptions. Please forgive me if I'm off base: 1. You're pretty new to Linux 2. You've had some prior experience with Microsoft's operating systems None of your problems were caused by Linux, Python, MySQLdb or Zope, but rather by your lack of familiarity with your OS. Hopefully, your three weeks in hell have taught you that it's time to spend some time getting to know Linux better. ;-) As a rule of thumb, you should never need to reformat your hard drive(!), nor reinstall Linux or Python. I repeat ... never! Too often, users of Win95/98/NT find themselves taking this kind of course, like when their DLLs get FUBAR'd, but that's almost never necessary with Linux. If you find yourself thinking you need to do this, stop. It's a sign you need to get some more information about what's happening. Everything you'll ever need to know about Linux is available for free on the Internet, but it can be hard to locate. So I strongly urge you to go out and purchase a good reference book. Matt Welsh's _Running Linux_ will do fine. Once you get your book, you want to do some reading about ldconfig, ld.so.conf, and LD_LIBRARY_PATH.
----- Original Message ----- From: "Patrick Phalen" <zope@teleo.net> To: <zope@zope.org> Sent: Saturday, April 01, 2000 8:20 AM Subject: Re: [Zope] MySQLDA and MySQLdb probs and solns
As a rule of thumb, you should never need to reformat your hard drive(!), nor reinstall Linux or Python. I repeat ... never! Too often, users of Win95/98/NT find themselves taking this kind of course, like when their DLLs get FUBAR'd, but that's almost never necessary with Linux.
Well.. I use Linux as well as NT for my Zope development and I never had to format my hard drive because of some DLL that went nuts... there are many other ways of solving this problem... but the main reason for windows users to choose the format command right away is the too little knowledge they have of ANY Operating system... bye --- Hugo Ramos - hramos@ruido-visual.pt Ruido Visual
// Damn. What a nightmare. // // Eric, I'm going to make some assumptions. Please forgive me if I'm off // base: // // 1. You're pretty new to Linux About 6 months old... // 2. You've had some prior experience with Microsoft's operating systems Too much prior experience! // None of your problems were caused by Linux, Python, MySQLdb or Zope, but // rather by your lack of familiarity with your OS. Hopefully, your three // weeks in hell have taught you that it's time to spend some time // getting to know Linux better. ;-) Yes, I just spent 3 weeks getting to know Linux and gcc better. I've learned a lot. // As a rule of thumb, you should never need to reformat your hard // drive(!), nor reinstall Linux or Python. I repeat ... never! Too often, // users of Win95/98/NT find themselves taking this kind of course, like // when their DLLs get FUBAR'd, but that's almost never necessary with // Linux. If you find yourself thinking you need to do this, stop. It's a // sign you need to get some more information about what's happening. I agree. I'm a "newbie", but not THAT new. I reformatted the hard drives because I decided to scrap the dual boot situation; Frankenstein is now a dedicated Linux box. Boy, I sure got flamed for saying that I reformatted! // Everything you'll ever need to know about Linux is available for free on // the Internet, but it can be hard to locate. So I strongly urge you to go // out and purchase a good reference book. Matt Welsh's _Running Linux_ // will do fine. Yes, finding the info is what always takes me the longest time. Here's a list of the books I've found to be good references: The Linux Network - Butzen and Hilton - This one is FANTASTIC! Linux Programmers Reference - Petersen GNU C++ for Linux - Swan and, although I hate to admit it, Linux for Dummies - Hall - This is a great general reference for Linux The Linux Programmer's Reference helped me the most on this particular problem. It had the best explanation of building and using libraries I could find. I was looking for a table of compiler switches with an explanation (a good explanation) of each switch. I never found one. This book had all the info, but it took a while to mine it all out. // Once you get your book, you want to do some reading about ldconfig, // ld.so.conf, and LD_LIBRARY_PATH. Actually, I did modify my ld.so.conf but going back to it I realize that, while I added "/usr/local/lib/mysql," I left out "/usr/local/lib". Now they are both in there. Hopefully this will help in the future. I couldn't find any info on LD_LIBRARY_PATH. Can you point me in the right direction? Thanks for the pointers! I still think the mailing lists are the best resource! Eric.
[Eric L. Walstad, on Sat, 01 Apr 2000] :: I couldn't find any info on LD_LIBRARY_PATH. Can you point me in the right :: direction? Once again, this is not a Zope question. I hesitate to get into this, because this is a (busy) Zope list, not a Unix system administration list. Also, because, like all things Unix, there are numerous ways to approach this and all Unices are a little different in this regard. So I'll confine this to the Linux case and also to my own preference. I'd encourage you to find out more on your own, in order to have the greatest flexibility. There are newsgroups for this subject. LD_LIBRARY_PATH (load library path) is a shell environment variable. As you may know, you have some built-in variables such as HOME and PATH. Others, like TERM, are not built in, but are so common that they are likely to be in your environment by virtue of being set in /etc/profile or elsewhere. It's A Good Idea to find out where all of yours are coming from. Any variable can become an environment variable. In the particular case of Linux, your default shell is Bash. In Bash, unlike csh and descendants, putting a variable in the environment entails defining and then exporting it. Doing so would be useless unless some program actually looks for that variable in the environment. In the case of LD_LIBRARY_PATH, that program is ld. If you haven't done so already, type 'man ld' and 'man ld.so' ld.so has the job of searching for shared library files. /etc/ld.so.conf contains a list of directories it searches. By default, ld.so always searches /lib and /usr/lib, regardless of the contents of ld.so.conf. Usually, there's no reason to modify ld.so.conf and many seasoned sysadmins will tell you to never modify it. Use LD_LIBRARY_PATH instead; that's what it's for. Type 'export' from the bash shell without arguments to see what environment variables you have right now. This is generally a good first step, for reasons I'll explain in a moment. In the Linux case, you can set and export LD_LIBRARY_PATH from the shell prompt, prior to any compilation attempt. LD_LIBRARY_PATH=/foo:/bar:/spam:/eggs export LD_LIBRARY_PATH For other variables, you may find that 'export' reveals that you already have a path in your environment and you may choose not to tromp on it. In that case, you can append to it: varname = varname:/extrastuff If you want a permanent repository for this (if bash is your shell), $HOME/.bash_profile is the place. /etc/profile is looked to first for all users, but your HOME environment takes precedence in this search. :: Thanks for the pointers! I still think the mailing lists are the best :: resource! Why, because it's easier for you? Expect to eventually get flamed if you: !. Don't RTFM. 2. Post off-target questions.
participants (4)
-
Eric L. Walstad -
Hugo Ramos -
Patrick Phalen -
Stephan Richter