0

I have Ubuntu 14.04 upgraded from 12.04 making dist-upgrades. I did many manual installations such as ffmpeg, libglib and so on, in the past. I have a nice custom distro now, it works well but I have problems while trying to compile applications. The errors I got taught me lots, I found how to deal with linker errors, I list some of them below:

how-can-i-guide-compiler-to-use-a-certain-library

how-to-fix-pkg-prog-pkg-config-command-not-found-error

pkg-config-modversion-glib-2-0-reports-older-version

how-to-fix-libgmodule-2-0-so-0-could-not-read-symbols-invalid-operation-erro

multiple-ffmpeg-library-paths-how-can-exclude-older-ffmpeg-installations

how-can-i-use-a-particular-library-while-compiling

I come to such a point that even I can get errors while compiling native Ubuntu applications such as unity (I want to embed unity launcher into cairo dock unity launcher in cairo dock)

How can I fix those library conflicts? I lost manually compiled application's directories so I have no chance to run make uninstall.

I am fed up with adjusting library paths. What do you suggest me in this position?

Community
  • 1
kenn
  • 5,162
  • Hopefully, the manual installations you did were in the /usr/local prefix. You could try removing everything in the bin, lib, etc. folders. (Don't remove the folders themselves.) – saiarcot895 Jul 15 '14 at 14:45
  • Build packages of the versions you want to install. You can probably use something like checkinstall to simplify things, but this way you can avoid at least side conflicts and use them like the official packages. – muru Jul 15 '14 at 15:44
  • @saiarcot895 Thank you for suggestion but I didn't get what you meant. If I remove everything in those directories how can I reinstall them? – kenn Jul 15 '14 at 19:06
  • @kenn: FFMpeg is in the repos and is now avconv in Trusty and libglib is in the libglib2.0-0 package, with development headers in libglib2.0-dev. There's a good chance that the packages and libraries you want are in the main repos and that you don't need to compile them. As you just discovered, if you decide to compile your own version and have it not managed by apt/dpkg, you will have to recompile it as library versions and SONAMEs change. – saiarcot895 Jul 15 '14 at 19:34
  • @saiarcot895 I followed this guide to install ffmpeg but it didn't fix library conflict https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu Then I used this repo https://launchpad.net/~jon-severinsson/+archive/ubuntu/ffmpeg, unfortunately the result is the same. Somehow linker uses old libraries. Here is the issue I got while compiling Simple Screen Recorder https://github.com/MaartenBaert/ssr/issues/215 – kenn Jul 15 '14 at 19:50
  • @kenn: Did you remove everything under /usr/local? (excluding the main folders) – saiarcot895 Jul 15 '14 at 19:52
  • @saiarcot895 No, I didn't remove anything. Everything? all of the files in it? Won't my system crash? – kenn Jul 15 '14 at 19:56
  • @kenn: No, it won't. Some applications that you compiled yourself probably won't run, but all official packages should keep working. – saiarcot895 Jul 15 '14 at 19:59
  • I have bandwidthd etc HTS-2.2beta lib man rvm share src bin games include libexec nagios sbin SPTK var in /usr/local – kenn Jul 15 '14 at 19:59
  • Don't remove the bin, etc, games, include, lib, man, sbin, share, or src folders; rather remove the files within them. You can (probably) keep any of the other folders and the files within them. – saiarcot895 Jul 15 '14 at 20:01
  • @saiarcot895 Thank you for info, I didn't know that. I ll try it tomorrow and let you know the outcome. – kenn Jul 15 '14 at 20:04
  • @kenn: See my post at https://github.com/MaartenBaert/ssr/issues/215. – saiarcot895 Jul 16 '14 at 11:53
  • @saiarcot895 Your solution works. Thank to you I could compile Simple Screen Recorder Would you please post it as an answer? It might be helpful to others. – kenn Jul 16 '14 at 14:06
  • @kenn: Will do. There was another thing I realized just now regarding linking that I'll post. – saiarcot895 Jul 16 '14 at 14:33

1 Answers1

1

The main issue here was the existence of libraries and includes in /usr/local that were compiled in Precise (12.04).

When searching for the development headers specified by #include, gcc and g++ have /usr/local/include higher on the list than /usr/include. Therefore, if you have a library's dev headers in both /usr/local/include and /usr/include, then the one in /usr/local/include will be used, regardless of the version. While this may have been fine in Precise, since the libraries that were locally compiled were likely newer versions, this wouldn't be fine in Trusty, when the system version of the library would be of a equal or newer version of the library you installed. In addition, as system libraries changed, the SONAMEs would have changed, and locally-compiled libraries would have to be recompiled. Therefore, gcc/g++ would use the older version and may complain about missing symbols and/or linking errors.

If a library is present in the main repos, it is generally recommended to use that library instead of compiling it by yourself (unless you need a newer version of a library for either development or to fix a bug); that way, when you upgrade your system, that library is updated as well, and recompiled to link correctly with the other libraries.

saiarcot895
  • 10,757
  • 2
  • 36
  • 39
  • Thank you for the info. I simply renamed usr/local to /usr/local.old and it did the trick. – kenn Jul 16 '14 at 15:01
  • WARNING renaming /usr/local folder to /usr/local.old works but it fails to boot. I used live USB to rename /usr/local.old/ back – kenn Jul 17 '14 at 08:32