Ruby'pg'gem链接到libpq.5.dylib的错误副本（在OSX上） [英] Ruby 'pg' gem linking to wrong copy of libpq.5.dylib (on OSX)

问题描述

PostgreSQL 9.3的EnterpriseDB安装程序将其文件放置在Mac OSX上的 /Library/PostgreSQL/9.3/ * 中。然而，Ruby gem'pg'从 / usr / lib 加载了旧版本的'C'动态库 libpq.5.dylib code>而不是使用 /Library/PostgreSQL/9.3/lib 中的正确版本。这会发生，尽管我已经安装了宝石

  gem install pg  -  --with-pg-config = / Library / PostgreSQL /9.3/bin/pg_config 
  

我确定了 libpq.5的哪个版本。在需要'pg'gem之前，通过设置DYLD_PRINT_LIBRARIES环境变量来加载dylib 。



链接到错误动态库的最明显后果是，gem无法使用域套接字连接到数据库，因为套接字在 / var / pgsql_socket 到 / tmp 。但是，链接到旧库也可能导致其他问题。

有关如何解决此问题的任何建议？

<其他注意事项：对于大多数pg库，EnterpriseDB安装程序将<静态（.a）和动态（.dylib）版本放入 / Library / PostgreSQL / 9.3 / lib ，但是 libpq.5 只安装了一个动态版本。）

解决方案

在我运行 bin / pg_config 时，问题的原因和简单的解决方案变得明显命令行。

pg_config 生成用于控制编译和链接的变量。特别感兴趣的是LIBDIR和LDFLAGS。 LIBDIR指定静态库的位置，而LDFLAGS提供位置来搜索动态库。在我的系统上，LIBDIR被正确设置为 /LibraryPostgreSQL/9.3/lib ，但LDFLAGS设置如下：

  LDFLAGS = -L ../../../ src / common -L / usr / local / lib -L ​​/ opt / local / 20140109 / lib -Wl，-dead- strip-dylibs 
  

由于 libpq.5.dylib 没有出现在这些位置中的任何一处，但是宝石未能找到它，而是发现恰好安装在 / usr / lib 中的旧版本。

解决此问题的一种方法是将正确的文件位置注入LDFLAGS，可能通过修改 extconf.rb 生成配置文件。然而，在这种情况下更容易的修复就是在 / usr / local / lib 中添加符号链接到正确的文件位置：

  / usr / local / lib> ln -s /Library/PostgreSQL/9.3/lib/libpq.5.dylib libpq.5.dylib 
  

如果遇到类似问题，请检查 pg_config 的输出，并查看是否可以将符号链接放置到其中一个已经存在的目录中正确的文件位置由LDFLAGS指定。

The EnterpriseDB installer for PostgreSQL 9.3 places its files in /Library/PostgreSQL/9.3/* on Mac OSX. However, the Ruby gem 'pg' loads a legacy version of the 'C' dynamic library libpq.5.dylib from /usr/lib instead of using the correct version from /Library/PostgreSQL/9.3/lib. This occurs despite my having installed the gem with

gem install pg -- --with-pg-config=/Library/PostgreSQL/9.3/bin/pg_config

I determined which version of libpq.5.dylib is loaded by setting the DYLD_PRINT_LIBRARIES environment variable, prior to requiring the 'pg' gem.

The most obvious consequence of linking to the wrong dynamic library is that the gem fails to connect to the database using a domain socket, because the socket was relocated between versions from /var/pgsql_socket to /tmp. However, linking to the old library may also cause other issues.

Any suggestions on how to fix this problem?

(I am running Mac OSX Lion. Additional note: For most pg libraries, the EnterpriseDB installer put both a static (.a) and a dynamic (.dylib) version in /Library/PostgreSQL/9.3/lib, but for libpq.5 installed only a dynamic version.)

解决方案

Both the cause of the problem and an easy solution became apparent when I ran bin/pg_config at the command line.

pg_config generates the variables that are used to control compilation and linking. Of particular interest are LIBDIR and LDFLAGS. LIBDIR specifies the location for static libraries, while LDFLAGS provides locations to search for dynamic libraries. On my system, LIBDIR was set correctly to /LibraryPostgreSQL/9.3/lib, but LDFLAGS was set as follows:

LDFLAGS = -L../../../src/common -L/usr/local/lib -L/opt/local/20140109/lib -Wl,-dead-strip-dylibs

Since libpq.5.dylib was not present at any of these locations, the gem failed to find it, and instead found an older version that happened to be installed at /usr/lib.

One way to fix this would be to inject the correct file location into LDFLAGS, possibly by modifying the code in extconf.rb that generates the config file. However, a much easier fix in this case is just to add a symlink in /usr/local/lib to the correct file location:

/usr/local/lib> ln -s /Library/PostgreSQL/9.3/lib/libpq.5.dylib libpq.5.dylib

If you run into a similar issue, just examine the output of pg_config, and see if you can place a symlink to the correct file location in one of the directories that is already specified by LDFLAGS.

这篇关于Ruby'pg'gem链接到libpq.5.dylib的错误副本（在OSX上）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！