pg_ext improperly linked when using rvm, ruby-devel and Ruby 2.0.3+

Issue #229 invalid
Anonymous created an issue

We are seeing an issue with Ruby 2.0.3+ where pg_ext.so is improperly linked to the system Ruby instead of the local RVM ruby when ruby-devel is installed. This issue has been seen on both EL6 and EL7 systems. Reproducer steps:

1) Install rvm 2) Install 2.0.3+ of Ruby into rvm environment (rvm install 2.0.4) 3) Ensure ruby-devel is installed on the system 4) 'gem install pg' into the rvm environment 5) ldd pg_ext.so and note the following:

$ ldd ./tmp/x86_64-linux/pg_ext/2.2.3/pg_ext.so | grep ruby
        libruby.so.1.8 => /usr/lib64/libruby.so.1.8 (0x00007fc20c1ab000)

6) Remove ruby-devel from the system 7) Remove pg from the rvm environment 8) 'gem install pg' again 9) ldd pg_exit.so and note the difference:

$ ldd ~/.rvm/gems/ruby-2.2.4/gems/pg-0.18.4/lib/pg_ext.so  | grep libruby
    libruby.so.2.0 => /usr/lib64/libruby.so.2.0 (0x00007fc025271000)

Comments (19)

  1. Dominic Cleal

    I helped Eric (who filed this issue) investigate it, so just adding a little more background. I think "Ruby 2.0.3" was meant to read "2.2.3".

    The problem seems to stem from adding the PostgreSQL library path via dir_config in extconf.rb (after it's looked up through pg_config). I tested both Ruby 2.0.0 and 2.2.3 - in 2.0.0, calling dir_config would append the PostgreSQL library path. This would cause linking to happen over paths /usr/local/rvm/rubies/ruby-2.0.0-p643/lib:/usr/lib64.

    Under Ruby 2.2.3, the lib path added through dir_config appears to be prepended, before the path of Ruby itself, resulting in linking with /usr/lib64:/usr/local/rvm/rubies/ruby-2.2.3/lib.

    When using RVM and a system Ruby (well, ruby-devel) is installed, libruby from /usr/lib64 is linked rather than the libruby in the RVM path.

  2. jamilbk

    This is biting me... any work-around? Seems like we should be able to override the lib path with something like gem install pg -- --with-opt-lib=/usr/local/rvm/rubies/ruby-2.2.3/lib no?

  3. ben wong

    I tried doing a bundle install and it's giving me this message :

    An error occurred while installing pg (0.18.4), and Bundler cannot continue. Make sure that gem install pg -v '0.18.4' succeeds before bundling.

    rails has never given me issues.

    Does it relate to this post? Thanks.

  4. Roger Lam

    I'm running into a similar issue on ruby 2.3.0

    LoadError: libruby.so.2.3: cannot open shared object file: No such file or directory - /srv/DelphiusApp/vendor/bundle/ruby/2.3.0/gems/pg-0.18.2/lib/pg_ext.so

  5. Michael Granger repo owner

    This is ultimately something that the gem itself cannot control or anticipate; it's up to the installer to provide a runtime environment that ensures the dynamic linker sees the same versions of the libraries a gem was installed with as when it's run.

    I'll add a way to disable pg_config in the extconf.rb so you don't have to comment it out, but that's all we can do. I'll ping this issue when I do and the next release (which will happen in the next few days) will include that.

  6. Eliezer Graber

    I'm experiencing this issue with Ruby 2.2.2 on Windows 10 (postgres 9.4.7). I receive this error every time I try to use the gem:

    LoadError: cannot load such file -- 2.2/pg_ext

    I've tried gem install pg --pre and got pg-0.19.0.pre20160409114042, but the issue is still there. Kind of a noob with this stuff, so I didn't really get any of the workarounds mentioned above.

  7. Shaig Khaligli

    I am having the same issue with rvm and ruby 2.3.0...When I try to install gem pg it says:

    Make sure that `gem install pg -v '0.18.4'` succeeds before bundling.
    

    and log file /home/shaig/.rvm/gems/ruby-2.3.0/extensions/x86_64-linux/2.3.0/pg-0.18.4/mkmf.log

    find_executable: checking for pg_config... -------------------- no


    find_header: checking for libpq-fe.h... -------------------- no

    "gcc -o conftest -I/home/shaig/.rvm/rubies/ruby-2.3.0/include/ruby-2.3.0/x86_64-linux -I/home/shaig/.rvm/rubies/ruby-2.3.0/include/ruby-2.3.0/ruby/ba$ checked program was: / begin / 1: #include "ruby.h" 2: 3: int main(int argc, char argv) 4: { 5: return 0; 6: } / end /

    "gcc -E -I/home/shaig/.rvm/rubies/ruby-2.3.0/include/ruby-2.3.0/x86_64-linux -I/home/shaig/.rvm/rubies/ruby-2.3.0/include/ruby-2.3.0/ruby/backward -I$ conftest.c:3:22: fatal error: libpq-fe.h: No such file or directory compilation terminated. checked program was: / begin / 1: #include "ruby.h" 2: 3: #include <libpq-fe.h> / end /


  8. Jonne Haß

    Another workaround is to set pg_config to garbage, making it fail and thus not add any lib path. This, like Alex Girdler's workaround, only works if the PostgreSQL libs are in a standard path. Manually exporting LIBRARY_PATH (not LD_LIBRARY_PATH) might also work in combination with this on setups that don't have the PostgreSQL libraries in their standard linker paths, but I did not verify that.

    The workaround is gem install pg -- --with-pg-config=/bin/none, for bundler do bundle config --local build.pg '--with-pg-config=/bin/none'.

    However it ought to be possible to guarantee correct ordering of things in extconf.rb, perhaps by not relying on the method but doing things manually.

  9. Kaio Cristian Costa Porto De Magalhães

    Any news on it? I'm facing the same issue on ruby 2.3.3

    /share/vendor/bundle/ruby/2.3.0/gems/pg-0.19.0/lib/pg.rb:4:in `require': libruby.so.2.3: cannot open shared object file: No such file or directory - /share/vendor/bundle/ruby/2.3.0/gems/pg-0.19.0/lib/pg_ext.so (LoadError)

  10. Log in to comment