语境：
在我们的服务器软件最近版本升级之后，我发现自己处于一个两难的境地：
我有两套应用程序（Zend服务器和各种实用程序，以及一些PostgreSQLpipe理工具），它们都大量使用某个库文件（libpq.so）。 Zend自带的libpq，这是唯一的版本（我发现），将与所有的Zend的东西。 Postgres还附带自己的版本库。 两者是相互排斥的：如果Postgres的库版本首先在任何用户正在做的事情的LD_LIBRARY_PATH中，那么所有的Postgres实用工具都可以工作，但是Zend的工具都不会。 如果Zend先来了，Zend的东西就可以工作，但Postgres的东西不会。
这两个库都有相同的名字。 PostgreSQL兼容性库包不起作用。
在我们的环境中，在很多不同的CentOS机器上，这两套应用程序都被用于很多不同的，不可预知的用户帐户，因此使用“正确的方式”并设置每个用户的LD_LIBRARY_PATH，并告诉人们“只使用X应用程序在Y帐户下“将不起作用。
题：
是否有一个每个应用程序的方式来说，“对于这些二进制文件/应用程序在X文件夹中执行，链接对库Ypath，但这些其他二进制文件，链接库Z”？ 基本上，每个应用程序库path，而不必每次访问其中一个应用程序时设置LD_LIBRARY_PATH或DYLD_ *。
我宁愿避免不得不重新编译库，因为每当新版本的软件出现时，这都会使我大量地麻烦和testing。 我已经有图书馆工作，他们只是不适用于这两套应用程序。
有一个选项会给你你想要的：
在构build应用程序时，您可以设置LD_RUN_PATH环境variables，并将其编译到应用程序中。 理论上chrpath命令可以让你在应用程序中修改embedded的path而不需要重新编译，但是我从来没有chrpathtesting过。
chrpath在Fedora中可用，但是我找不到源代码的权威来源。
你提到DYLD_*variables，这表明你正在OS X下工作，在这种情况下，上述可能不适用于你。 这对于Linux来说当然是正确的，但OS X运行时链接程序可能不会以相同的方式运行（chrpath可能是仅限于Linux的工具）。
pipe理每个应用程序LD_LIBRARY_PATH设置的常用方法是按照ewwhite的build议使用包装器脚本，或者使用类似于Environment Modules项目的东西。 这使您可以将环境variables设置（以及更多）打包到不同的单元中，以便执行类似以下操作：
module load myapplication
并有您的PATH ， LD_LIBRARY_PATH ， MANPATH和其他一切设置适当的访问我的应用程序。 完成后，您可以：
module unload myapplication
撤销环境更改。
在我的背景下，这个常用的方法是使用包装脚本来执行应用程序。 在该包装脚本中，将为特定应用程序设置LD_LIBRARY_PATH。 执行完成后，该variables可以有select地取消设置。