Today I updated my laptop to Ubuntu 18.04.
Now I try to run a program for my bachelor thesis, but it gives me the following error message:
error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory
I did a bit of research, and I think libmpfr4 has been droppen in this ubuntu version. Is there any way I can solve this?
I had the same problem and solved it by creating symbolic link:
sudo ln -s /usr/lib/x86_64-linux-gnu/libmpfr.so.6 /usr/lib/x86_64-linux-gnu/libmpfr.so.4
Bear in mind that this is just workaround which might trigger other issues for your case. However, this might save you the day in cases when the problematic program is just a mean to achieve something else.
When you get such an error, this means that you generally need to recompile your program.
Alternatively, you may install the old MPFR 3.x version (which corresponds to libmpfr.so.4) if available, otherwise from an earlier Ubuntu release (I do not recommend that, but if there are no conflicts from the packaging system, this could be OK; FYI, in Debian, both packages libmpfr4 and libmpfr6 are co-installable).
Note: Contrary to what has been said in the comments, libmpfr.so.4 is no longer there if you're using the 64-bit ABI (x86_64), as ldconfig -p | grep mpfr gave for this file: /usr/lib/i386-linux-gnu/libmpfr.so.4, i.e. the 32-bit version. I suspect that the upgrade removed the x86_64 one (either due to a conflict or because it was no longer needed).
apt install python-gmpy2 can fix this error.
Related
i'm learning linux kunnel programming. however, i faced problem that gcc version is too high to execute 2.4kunnel "make" command(make bzImage), I try to find solution. but in debian case solution does not exist, just for ubuntu, centOs ect... please help me Or, link that about my problem.
P.S ) What i want version of gcc is 3.3 version, it doesn't work use command apt-get install gcc-3.3
Why would you learn based on 2.4?
Your question is wrong anyway. You will likely need other old tools. The way to go is to download an entire debian system and chroot inside. This can be achieved with debootstrap.
However, as noted earlier, you should not stick to 2.4 in the first place.
The mysql++ package that comes from tangentsoft, is version 3.1.0 and I am having trouble building on my linux system. To get it to configure I had to specify the with the flag
./configure --with-mysql-lib=/usr/lib/i386-linux-gnu/
Otherwise there was a problem with it finding the mysqlclient library. Now unfortunately it wont make, the error I get is ./lib/refcounted.h:258:2: error: ‘size_t’ does not name a type, after I type make and before I type make install.
Has anyone had the same problem with compiling it, and did you find a solution?
Any help it solving this problem is appreciated.
There are a few #include fixes in the svn version of MySQL++ that haven't yet been included in a release version. They're necessary on modern OSes like yours, which include recent GCCs and libstdc++'s.
Don't be nervous about using the svn version in production. It's quite stable at the moment. My reasons for not releasing it as-is aren't related to stability.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to upgrade libpng from version 1.2 to 1.5. I need to do so because of this: libpng warning: Application built with libpng-1.2.26 but running with 1.5.2. I am using Lubuntu 11.10 and in the Canonical repositories libnpg 1.5 is not still released although at Debian ones there are testing packages (http://packages.debian.org/search?keywords=libpng) that at first they would fit to me. I added the Debian repositories to Synaptec and I was able to install libpng15, but those packages do not replace libpng12, son when it comes to compile some source code the IDE uses libpng12 instead of libpng15.
To try to solve this I downloaded the libpng15 deb package, uncompressed it and changed the Replaces, Conflicts and Provides tags of the control file with the libpng15 text. Then, I executed the modified deb, but what I only got was a GDebi error and a general system failure because (I think) libpng12 was uninstalled with no replacement and Lubuntu heavily depends on it, which forced me to reinstall Lubuntu because the computer did not boot again in Linux. Yes, this solution is not the neatest way I think.
So, is there any way to upgrade a package and replace the old version whose newer version exists but it is not still in the distribution repository? I found ubuntu repository for libpng and How to upgrade a package in linux that was built from source?. Although not very determinant so far.
I have not found out how to upgrade and replace a package whose newer version is not still in the distribution repository. But I have realized that if some library X relies on a given version of other library Y, there is no way to change the version of that dependence unless you make some change onto the source code of X, that is it, the library X is recompiled to point to the desired version (usually with the help of some configuration tag). Even though some trick could be done as by modifying the symlink of the library Y to point to the newer version. Then, the compiler will complain and ask for the old version.
Maybe this looks obvious now. But if the software that has to be recompiled requires many hours, has unresolved dependences or gives built errors you will try to avoid the compilation no matter if you are violating thermodynamics laws.
So in my case I had to recompile Qt and by using the -system-libpng configuration tag Qt understood it had to use system libpng libraries, not in-built ones. And after 8 hours of compiling I got a successfully built which solved this libpng problem.
Thanks everyone for the comments and suggests.
For all of the trouble you're going through, it might be easier to simply compile from source, and install to /usr/local (instead of /usr, as debs do). I've done this for several library dependencies for programs I've compiled (with make build systems) without any trouble. However, it sounds like the program(s) you're compiling are having trouble choosing the right version of the package. In my opinion, that is the real issue. Having multiple versions of a library installed simultaneously is supported, but perhaps not by apt in the case of mixing Debian and Ubuntu repos.
When you compile your program, use gcc -lpng15 instead of -lpng. According to the gcc info manual, an option of -lname causes the linker to look for libname.a in the lib folders. On my system (Ubuntu 10.04), libpng.a is a symlink to libpng12.a. This is why your program is choosing the wrong lib.
Try adding this ppa: https://launchpad.net/~linaro-maintainers/+archive/overlay. It contains libpng1.5 for Oneiric.
You can install it by running
sudo add-apt-repository ppa:linaro-maintainers/overlay
sudo apt-get update
sudo apt-get install libpng1.5
To properly link against libpng15, you will also need to install libpng15-dev.
I'm attempting to build a binary package that can be run on multiple Linux distributions. It's currently built on Ubuntu 10.04, but it fails on Ubuntu 8.04 with the following error:
./test: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./test)
./test: /usr/lib/libstdc.so.6: version `GLIBC_2.11' not found (required by ./test)
What's the preferred way to solve this problem? Is there a way to install an old glibc on a new box and build against it, or do I have to build on an old distribution? And if I build against an old glibc, will it work on a new glibc?
Or, alternatively, are there just some handy compiler flags or packages I could install to solve the problem?
The best solution I've found is to install a virtual machine running Debian stable, and build on that. Debian stable is old enough that any packages built with it will run on any other Debian-based distribution like Ubuntu. You may have to work around non-critical bugs that have been fixed in later versions of various software but not backported to Debian stable.
If you really want to make sure it runs on every recent distribution, you might also consider statically linking against a libC you select. However you may then still run into problems if you use features that are only provided by newer kernels (newer system calls e.g.).
Can I install an older version of gcc/g++ (4.1.3) on the latest Ubuntu (which comes with 4.4.3) and use it to compile a .so which should run on CentOS? The binary compiled with the Ubuntu version of gcc fails to load on CentOS because of missing imports (GLIB_2_11, ...). I need C++ (including exceptions), so I can't just statically link against glibc, which I already tried.
Can I install the older gcc without removing the newer one? How do I go about the libs required by the older gcc?
I'm currently developing code in CentOS, but it's such a pain to use. I really want to move to an Ubuntu desktop.
g++-4.1 is available for Ubuntu; just run apt-get install g++-4.1 then run g++-4.1 instead of g++. However, simply using an older compiler may not fix all of your library issues.
Like Joachim Sauer said, your best bet is to do your development on Ubuntu then do the final compilation on CentOS.
Even though you're using C++, static linking should still be an option. (However, you're much better off compiling on CentOS and using dynamic linking.)
Edit: A virtual machine is the most straightforward way to build on CentOS, but if you want to avoid the memory and CPU overhead of running a VM and don't care about differences between Ubuntu's and CentOS's kernel, then you can create a subdirectory containing a CentOS or Fedora filesystem and chroot do that to do your builds. This blog posting has details.