MySQL trouble on different linux distributions
BlitzMax Forums/Brucey's Modules/MySQL trouble on different linux distributions
| ||
| Hi, I did my first Linux app - developed under Windows with Bruceys DB mods accessing a MySQL server. Than I compiled it unter Ubuntu 12.04 and it works fine. But when I try to start it under another distribution (Debian I think) I get an error: error while loading shared libraries: libmysqlclient.so.18: cannot open shared object file: No such file or directory I read two hours google results and tried all I found beginning apt-get update apt-get upgrade apt-get install libmysqlclient15-dev ... (a fistful more hints I found) But I can't make it work. What is the right package for? Thanks Andre |
| ||
| It probably is looking for the library in the wrong place. Either copy the file to your source code directory or make sure that the link directory points correctly to where the library is. When you're on 64-Bit Linux, you also have to make sure that you are using a 32-Bit version of the library. On 64-Bit Linux, 32-Bit library-versions are not installed by default. |
| ||
| I figured out that's a problem with Debian 6 as there's a bug for the libmysqlclient18 package. When I try apt-get install libmysqlclient18 I get an error that's not found. I read a solution would be to use a static link for - do you know how that can work or is there a way to install without apt-get ? |
| ||
| You need to be reasonably careful building on one Linux distro and running on another, especially in these cases where perhaps the naming of the shared objects differ, or one distro uses a newer/older version. If the versions are different, yet reasonably close, you can usually get away with sym-linking the file you need to the file that is actually there. If the ABI hasn't changed it generally works fine. For example, on one system you build your gui against libmysqlclient.so, which itself is symlinked to libmysqlclient.so.18 (the actual shared object). When you move to another system, you find that there is a file libmysqlclient.so.16 instead, say. Well, may be able to do something like : ln -s /path/to/libmysqlclient.so.16 /path/to/libmysqlclient.so.18 and the chances are it will work - if the versions are similar. |
| ||
| Brucey?!?! |
| ||
| Well, here is a different example… A version Sage Line 500 on Linux was built requiring Oracle 9 libraries. They said they did not have a version for Oracle 10 (yet), and I could not wait for them to maybe one day build a version linked to the Oracle 10 libraries that we had installed on the server. So, I added a symbolic link which tricked the application to think it was loading one library (Oracle 9) when it was in fact loading another (Oracle 10). Since the ABI (list of functions and their parameters) is fairly static between versions, everything just worked. When you run the "ldd" command on your binary, you can see what libraries it expects to find, the full path to them if they exist, and "not found" if it can't find them. Of course, the other option would be to runtime-load the shared library instead, but it always seems a bit clunky when I can instead just add "-lsomething" :-) |
| ||
| Holy crap, it's Brucey! I thought you had been recruited by NASA, Microsoft or Intel (or quite possibly by aliens)! Well, I hope life treats you well, and it's good to hear from you again! Russell p.s. You've done so much for the Blitz community, I'm almost afraid to ask, but is there any chance you could update some of your modules for the latest versions of the libraries they wrap/link to? A good many of them no longer compile anymore. :( |
   |