PostgresApp / PostgresApp

The easiest way to get started with PostgreSQL on the Mac
https://postgresapp.com
Other
7.33k stars 382 forks source link

pg gem 0.15.1 + postgres.app 9.2.4 = more dylib issues #109

Closed swrobel closed 11 years ago

swrobel commented 11 years ago
/Users/swrobel/.rvm/gems/ruby-1.9.3-p392@global/gems/polyglot-0.3.3/lib/polyglot.rb:63:in `require': dlopen(/Users/swrobel/.rvm/gems/ruby-1.9.3-p392@cult/gems/pg-0.15.1/lib/pg_ext.bundle, 9): Library not loaded: @executable_path/../lib/libssl.1.0.0.dylib (LoadError)
  Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib
  Reason: image not found - /Users/swrobel/.rvm/gems/ruby-1.9.3-p392@cult/gems/pg-0.15.1/lib/pg_ext.bundle

I've tried both gem install pg and gem install pg -- --with-pg-config=/Applications/Postgres.app/Contents/MacOS/bin/pg_config and both lead to the same result.

Anyone else seeing this? I'd like to revert to 9.2.2 but I can't find a download link...

swrobel commented 11 years ago

Found 9.2.2 here: http://postgres-app.s3.amazonaws.com/PostgresApp-9-2-2-0.zip

Confirmed that downgrading fixed the problem.

jcoby commented 11 years ago

I had the same issue. Downgrading to 9.2.2 fixed it for me as well.

anthonator commented 11 years ago

Ran into the same issue.

frabrunelle commented 11 years ago

I had to downgrade to 9.2.2 as well.

rmg commented 11 years ago

Another downgrade to 9.2.2 here. Is this related to 0897d9bee28105cf4bab493344e5d550ffd5a0ba maybe?

ghost commented 11 years ago

Had to downgrade also on my end.

benniemosher commented 11 years ago

I had to downgrade as well.

mech commented 11 years ago

Have the same issue. I need the uuid to play with Rails 4. But when I rake db:drop, the whole thing blow:

dlopen(/Users/mech/.rvm/gems/ruby-2.0.0-p0@xx/gems/pg-0.15.1/lib/pg_ext.bundle, 9): Library not loaded: @executable_path/../lib/libssl.1.0.0.dylib
Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib
Reason: image not found - /Users/mech/.rvm/gems/ruby-2.0.0-p0@xx/gems/pg-0.15.1/lib/pg_ext.bundle

The pg gem does install fine. The rails dbconsole works and can query also. Just that migration don't work :(

bsy commented 11 years ago

Adding the following to my .bash_profile did the trick to fix this loading issue (on rails 3.2.13 + ruby 1.9.3p194) :

export DYLD_LIBRARY_PATH=/Applications/Postgres.app/Contents/MacOS/lib:$DYLD_LIBRARY_PATH

mech commented 11 years ago

Add @bsy suggestion and it expose another issue with nokogiri :(

dlopen(/Users/mech/.rvm/gems/ruby-2.0.0-p0@xx/gems/nokogiri-1.5.9/lib/nokogiri/nokogiri.bundle, 9): Library not loaded: /usr/local/opt/libxml2/lib/libxml2.2.dylib
Referenced from: /Users/mech/.rvm/gems/ruby-2.0.0-p0@xx/gems/nokogiri-1.5.9/lib/nokogiri/nokogiri.bundle
Reason: Incompatible library version: nokogiri.bundle requires version 12.0.0 or later, but libxml2.2.dylib provides version 10.0.0 - /Users/mech/.rvm/gems/ruby-2.0.0-p0@xx/gems/nokogiri-1.5.9/lib/nokogiri/nokogiri.bundle

I guess it fix some, but not the other similar "dylib" problems.

bsy commented 11 years ago

@mech yeah after I fixed that, I noticed it broke node.js, downgrade it is!

pda commented 11 years ago

Same problem. Seems the dependency loading in libpq.dylib bundled with Postgres.app is broken, specifically with reference to loading the bundled libssl.

Here's ruby with the system libpq:

pda@paulbook ~ ⸩ DYLD_INSERT_LIBRARIES=/usr/lib/libpq.dylib ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.0]

Here's ruby with the Postgres.app libpq:

pda@paulbook ~ ⸩ DYLD_INSERT_LIBRARIES=/Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib ruby -v
dyld: Library not loaded: @executable_path/../lib/libssl.1.0.0.dylib
  Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib
  Reason: image not found

And an otool dump:

pda@paulbook ~ ⸩ otool -L /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib
/Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib:
        /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib (compatibility version 5.0.0, current version 5.5.0)
        @executable_path/../lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        @executable_path/../lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

Note that @executable_path/../lib/libssl.1.0.0.dylib is presumably trying to refer to /Applications/Postgres.app/Contents/MacOS/lib/libssl.1.0.0.dylib.

Loading just that libssl against ruby results in a similar error:

pda@paulbook ~ ⸩ DYLD_INSERT_LIBRARIES=/Applications/Postgres.app/Contents/MacOS/lib/libssl.1.0.0.dylib ruby -v
dyld: Library not loaded: @executable_path/../lib/libcrypto.1.0.0.dylib
  Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libssl.1.0.0.dylib
  Reason: image not found

Here's the otool dump of that libssl:

pda@paulbook ~ ⸩ otool -L /Applications/Postgres.app/Contents/MacOS/lib/libssl.1.0.0.dylib
/Applications/Postgres.app/Contents/MacOS/lib/libssl.1.0.0.dylib:
        /Applications/Postgres.app/Contents/MacOS/lib/libssl.dylib (compatibility version 1.0.0, current version 1.0.0)
        @executable_path/../lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

In this case, @executable_path/../lib/libcrypto.1.0.0.dylib refers to /Applications/Postgres.app/Contents/MacOS/lib/libcrypto.1.0.0.dylib.

Loading just that libcrypto against ruby works fine:

pda@paulbook ~ ⸩ DYLD_INSERT_LIBRARIES=/Applications/Postgres.app/Contents/MacOS/lib/libcrypto.1.0.0.dylib ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.2.0]

Presumably that's because it has no more @executable_path references:

pda@paulbook ~ ⸩ otool -L /Applications/Postgres.app/Contents/MacOS/lib/libcrypto.1.0.0.dylib
/Applications/Postgres.app/Contents/MacOS/lib/libcrypto.1.0.0.dylib:
        /Applications/Postgres.app/Contents/MacOS/lib/libcrypto.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

Hope this helps in some way — I'm afraid I have no idea how to help fix it.

pda commented 11 years ago

Also worth noting regarding the bundled OpenSSL build, OPENSSLDIR is hard-coded to /Users/mattt/Desktop/PostgresApp/Postgres/Vendor/postgres/ssl. Maybe related?

pda@paulbook ~ ⸩ /Applications/Postgres.app/Contents/MacOS/bin/openssl version -a | grep OPENSSLDIR
WARNING: can't open config file: /Users/mattt/Desktop/PostgresApp/Postgres/Vendor/postgres/ssl/openssl.cnf
OPENSSLDIR: "/Users/mattt/Desktop/PostgresApp/Postgres/Vendor/postgres/ssl"
EnriqueCanals commented 11 years ago

I had the same issue. Downgrading worked for me as well.

dlopen(/Users/enrique/.rvm/gems/ruby-2.0.0-p0@rails-3.2.13/gems/pg-0.15.1/lib/pg_ext.bundle, 9): Library not loaded: @executable_path/../lib/libssl.1.0.0.dylib Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib Reason: image not found - /Users/enrique/.rvm/gems/ruby-2.0.0-p0@rails-3.2.13/gems/pg-0.15.1/lib/pg_ext.bundle

tmcallister commented 11 years ago

Same as above. Downgraded to 9.2.2 to fix. Env: Ruby 2 / Rails 4.

dylansm commented 11 years ago

@tmcallister I downgraded by quitting the app and copying version 9.2.2 over 9.2.4 without issue.

iscott commented 11 years ago

Thanks @swrobel - had the same issue and downgrading fixed it. Thanks for posting the link!

albrow commented 11 years ago

I didn't want to downgrade, so after trying a few different solutions I found one that worked for me.

Add the following to your .bash_profile and restart the terminal session. export DYLD_FALLBACK_LIBRARY_PATH=/Applications/Postgres.app/Contents/MacOS/lib:$DYLD_LIBRARY_PATH

It is essentially the same as @bsy's solution but it doesn't screw up other apps that might be depending on DYLD_LIBRARY_PATH.

HLGgithub commented 11 years ago

@stephenalexbrowne your export worked for me... thank you!!

ajb commented 11 years ago

another downgrade here. caused a major headache this evening :cry:

andershaig commented 11 years ago

I just wanted to say thanks @stephenalexbrowne and let others know his solution worked for me as well when some of the other suggestions failed. I also like that it's easily removable when this issue is fixed.

mrmurphy commented 11 years ago

@stephenalexbrowne thanks for that temporary fix. EDIT:

Inserting the line: export DYLD_FALLBACK_LIBRARY_PATH=/Applications/Postgres.app/Contents/MacOS/lib:$DYLD_LIBRARY_PATH in my .zshrc fixes the problem when looking for libssl, but then, when I launch psql I get this error:

dyld: Library not loaded: @executable_path/../lib/libedit.3.dylib Referenced from: /Applications/Postgres.app/Contents/MacOS/bin/psql Reason: image not found

I don't know why this would happen. There's no libedit.3.dylib inside lib. So I don't know why removing that file from my .rc fixes the issue. Any ideas?

I also downgraded, which fixed the loading error, but it wraps an older version of SSL, so I got this back from python: _psycopg.so requires version 1.0.0 or later, but libssl.0.9.8.dylib provides version 0.9.8

memoht commented 11 years ago

Ran into exact same problems outlined here. Currently sitting back at 9.2.2.0 until this is sorted out.

lukemelia commented 11 years ago

I'm experiencing the same ilbedit.3.dylib issue as @murphyrandle with the DYLD_FALLBACK_LIBRARY_PATH workaround. It occurs when I try to run psql.

albrow commented 11 years ago

@lukemelia and @murphyrandle: I can verify that I have the same problem with psql. Unsetting the env variable seems to fix the issue (but then it breaks rails).

The following command will unset the DYLD_FALLBACK_LIBRARY_PATH environment variable temporarily. It does this by entering a "subshell" which does not alter your current bash environment. After you exit psql it will be set again so that rails (and probably some other things that depend on Postgres.app) will function properly.

(. ~/.bash_profile; unset DYLD_FALLBACK_LIBRARY_PATH; psql)

This is assuming that you're using bash and that your .bash_profile is located in your home directory. If that's not the case (or if you're using a .bashrc or other environment setup instead of .bash_profile) change the ~/.bash_profile part of the command to the path to your environment setup script.

If you don't want to type all that out, you can create an alias in your .bash_profile (or equivalent). Something like:

alias psql="(. ~/.bash_profile; unset DYLD_FALLBACK_LIBRARY_PATH; psql)"

This will automatically and temporarily unset the DYLD_FALLBACK_LIBRARY_PATH when you run psql. It's not ideal, but I tested it and it works for me.

mrmurphy commented 11 years ago

That's a great workaround. Thanks!

Murphy Randle Python Monkey, Space Monkey Inc. http://www.MurphyRandle.com

On Saturday, May 25, 2013 at 9:31 PM, Alex Browne wrote:

@lukemelia (https://github.com/lukemelia) and @murphyrandle (https://github.com/murphyrandle): I can verify that I have the same problem with psql (and with rails dbconsole). Unsetting the env variable seems to fix the issue (but then it breaks rails).
The following command will unset the DYLD_FALLBACK_LIBRARY_PATH environment variable temporarily. It does this by entering a "subshell" which does not alter your current bash environment. After you exit psql it will be set again so that rails (and probably some other things that depend on Postgres.app) will function properly. (. ~/.bash_profile; unset DYLD_FALLBACK_LIBRARY_PATH; psql) This is assuming that you're using bash and that your .bash_profile is located in your home directory. If that's not the case (or if you're using a .bashrc or other environment setup instead of .bash_profile) change the ~/.bash_profile part of the command to the path to your environment setup script. If you don't want to type all that out, you can create an alias in your .bash_profile (or equivalent). Something like: alias psql="(. ~/.bash_profile; unset DYLD_FALLBACK_LIBRARY_PATH; psql)" and optionally alias dbconsole="(. ~/.bash_profile; unset DYLD_FALLBACK_LIBRARY_PATH; bundle exec rails dbconsole)" if you want to use rails dbconsole.
This will automatically and temporarily unset the DYLD_FALLBACK_LIBRARY_PATH when you run psql or dbconsole. It's not ideal, but I tested it and it works for me.

— Reply to this email directly or view it on GitHub (https://github.com/PostgresApp/PostgresApp/issues/109#issuecomment-18457400).

mrmurphy commented 11 years ago

Hmm, so I downloaded the source and did my own build. That seemed to have fixed my problems.

realdoug commented 11 years ago

@murphyrandle yea, according to issue #113 it may a problem introduced by this commit: https://github.com/PostgresApp/PostgresApp/commit/0897d9bee28105cf4bab493344e5d550ffd5a0ba

Is that plausible at all?

dylansm commented 11 years ago

Building it from source worked for me, too. Thanks, @murphyrandle! (Had to do it ...I really like that new retina menu icon....)

jakob commented 11 years ago

The reason for the dylib troubles are the way we defined the paths. When we link libpq to libssl, we could use a path like /Applications/Postgres.app/Contents/MacOS/lib/libssl.dylib, but then Postgres.app would only work if you moved it to your Applications folder. We want Postgres.app to also work when the user opens it directly from the Downloads folder, so we use a relative path like @executable_path/../lib/libssl.dylib. This works great for the postgres and psql binaries inside the Postgres.app package. But it doesn't work when something outside of the package, like a ruby gem, wants to use our libraries -- because then the relative path from executable to library isn't correct anymore.

I think @harrijauri might have a solution for this problem in this commit: https://github.com/harrijauri/PostgresApp/commit/25c4914d5662f8248e529b249e2beb6ec80507ed
His solution is to use @loader_path instead of @executable_path. Unfortunately, his solution is written in a ruby script, which is a bit hard to understand for me, so I'm not totally sure what he does, but it might fix this problem. I'll have a look.

dfuentes77 commented 11 years ago

same here, reverted to 9.2.2.0

jwaldrip commented 11 years ago

I am reverting to hombrew until a more stable product can be delivered. Please keep me informed.

gverri commented 11 years ago

Is 9.2.2 working fine for you? Or should I go back to default?

pruett commented 11 years ago

+1 for downgrading to 9.2.2.0; fixed the following issues (Rails 3.2.13):

dlopen(/Users/pruett/.rbenv/versions/2.0.0-p195/lib/ruby/gems/2.0.0/gems/pg-0.15.1/lib/pg_ext.bundle, 9): Library not loaded: @executable_path/../lib/libssl.1.0.0.dylib
  Referenced from: /Applications/Postgres.app/Contents/MacOS/lib/libpq.dylib
  Reason: image not found - /Users/pruett/.rbenv/versions/2.0.0-p195/lib/ruby/gems/2.0.0/gems/pg-0.15.1/lib/pg_ext.bundle
mrmurphy commented 11 years ago

So, is anybody maintaining this app still? And thanks for the great answer, @jakob

wlgithub commented 11 years ago

export DYLD_FALLBACK_LIBRARY_PATH=/Applications/Postgres.app/Contents/MacOS/lib:$DYLD_LIBRARY_PATH

works, but it breakdown autotest and rspec etc

So I had to use

export DYLD_FALLBACK_LIBRARY_PATH=/Applications/Postgres.app/Contents/MacOS/lib:/usr/lib:/usr/local/lib:$DYLD_LIBRARY_PATH

pboling commented 11 years ago

So it seems that out of the box the current Postgres.app (v9.2.4.0) is not compatible with Ruby development utilizing the pg gem. Is this a correct analysis of the current state of things? It seems to be what I've just experienced on my team. None of the solutions we tried worked, and we were unable to find the old 9.2.2 Postgres.app online, so now we are Airdropping it everywhere.

PostgresApp v9.2.2.0 works.

memoht commented 11 years ago

@pboling Farther up in this thread @swrobel provided a link to the 9.2.2.0 version. http://postgres-app.s3.amazonaws.com/PostgresApp-9-2-2-0.zip

vamshionrails commented 11 years ago

Simply do

sudo ln -s /Library/Postgresql/9.2/lib/libpq.5.dylib /usr/lib/libpq.5.dylib

Vamshi

jakob commented 11 years ago

I'm sorry for taking so long to find a fix for this issue, after all I caused the problem by boundling openssl. (which is a good thing, if it wouldn't break the pg gem)

I have now made a beta build of 9.2.4 to address this issue. Could somebody try if this beta fixes the issue? https://s3-eu-west-1.amazonaws.com/eggerapps.at/postgresapp/PostgresApp-Core-9.2.4-Beta1.zip

Note: This beta includes PostgreSQL core only (no PostGIS, no plv8)

memoht commented 11 years ago

I just downloaded the Beta and was able to successfully fire up my Rails apps and connect to the database, so it appears this is working. I'll run with it for a bit and see if it works out. Thanks for working on resolving this issue.

henrrrik commented 11 years ago

Beta works for me too.

gverri commented 11 years ago

Seems to be working here too.

dotpao commented 11 years ago

Beta version works fine

hadiS commented 11 years ago

Beta works for me.

cmattson commented 11 years ago

Beta's working fine here too.

JacobEvelyn commented 11 years ago

Beta works for me too.

motymichaely commented 11 years ago

Beta works for me too.

wycats commented 11 years ago

@jakob is the solution to use @loader_path. I hit these issues when trying to use Postgres.app with Tokaido and was able to resolve them via @loader_path.

jakob commented 11 years ago

@wycats yes, the solution uses @loader_path. The beta is just a build of commit 1fa960ea63d8a911db96e0226115f4e5cb445eed referenced above. I'm very busy at the moment, as soon as I have time I will finish the refactoring so the extensions (PostGIS, plv8) are compiled as well.