I've been diving into dependency hell on an embedded Yocto Linux project recently in an attempt to compile and install a large project. I frequently run into an error while installing the dependencies (usually during the configure/make/make install steps) that a library can't be found. I'll take a quick look in /usr/lib or /lib and sure enough, the .so file is right there.

For example, if it complains it can't find libfoo, I'll look in /usr/lib and see this:

$ ls /usr/lib/libfoo*  
libfoo.so.3    libfoo.so.3.5.2

I figured out that the linker was strictly looking for libfoo.so, so I created a soft link:

$ ln -s /usr/lib/libfoo.so.3.5.2 /usr/lib/libfoo.so

And then suddenly the linker could find it during compile and was happy.

Why do I need to do this sometimes? Is this considered normal procedure when manually installing dependencies from source or is there some step I'm missing that I should be doing?

Here's my uname output if that's useful:

$uname -a
Linux ventana 3.14.48-1.0.x-ga+yocto+gd9991ca #1 SMP Wed Apr 18 15:23:20 MST 2018 armv7l GNU/Linux

1 Answer 1


Generally, if a project has undergone several major versions, it's unwise to have a bare .so, because major version changes often reflect incompatible ABIs. Only having versioned library files prevents a program from "successfully" linking, only to have the resulting program fail in mysterious ways when you update the symlink. (Windows had similar problems where older DLLs didn't usually use versioning, and installers frequently replaced them with incompatible versions, resulting in "DLL Hell".)

I would check the README (or equivalent) file to see what the requirements are, and run configure --help to see if you can override the fallback guesses that it made; that will also have the benefit of binding the program to the correct version of the library.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .