在g++编译期间，如果使用-Loption改变Makefile可能不合适，则通过make define LIBRARY_PATH。我把额外的库放在/opt/lib中，所以我做了:

$ export LIBRARY_PATH=/opt/lib/

然后运行make以成功编译和链接。

使用共享库运行程序定义:

$ export LD_LIBRARY_PATH=/opt/lib/

在执行程序之前。

这是我笔记本电脑的Ubuntu信息。

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

我使用locate查找boost_filesystem和boost_system的.so文件

locate libboost_filesystem
locate libboost_system

然后将.so文件链接到/usr/lib并重命名为.so

sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 /usr/lib/libboost_filesystem.so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 /usr/lib/libboost_system.so

完成了!R包velocyto。R安装成功!

似乎没有任何答案可以解决初学者在第一时间未能安装所需库的常见问题。

在Debianish平台上，如果libfoo缺失，你可以经常用类似的东西来安装它

apt-get install libfoo-dev

开发工作需要包的-dev版本，即使是简单的开发工作，如编译源代码以链接到库。

包名有时需要一些修饰(libfoo0-dev?没有lib前缀的Foo-dev ?等等)，或者你可以简单地使用发行版的包搜索来精确地找出哪些包提供了特定的文件。

(如果有不止一个，你需要找出它们之间的区别。选择最酷或最受欢迎的是一种常见的捷径，但对于任何严肃的开发工作来说都不是可接受的过程。)

对于其他体系结构(最明显的是RPM)，应用类似的过程，尽管细节有所不同。

当你编译你的程序时，你必须提供库的路径;在g++中使用-L选项:

g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar

除了已经给出的答案，也可能是*。因此文件存在，但没有正确命名。也可能是*。所以文件存在，但它由另一个用户/ root拥有。

问题1:名称不当

如果您将文件链接为-l<nameOfLibrary> 那么库文件名必须是lib<nameOfLibrary>的形式 如果你只有<nameOfLibrary>。重命名文件!

问题2:错误的所有者

为了验证这不是问题-做

ls -l /path/to/.so/file

如果文件由root或其他用户拥有，则需要执行

sudo chown yourUserName:yourUserName /path/to/.so/file

如果符号链接是指向动态库的，也会出现这个错误。.so，但是由于遗留的原因-static出现在链接标志中。如果是，试着把它去掉。