Closed swrobel closed 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.
I had the same issue. Downgrading to 9.2.2 fixed it for me as well.
Ran into the same issue.
I had to downgrade to 9.2.2 as well.
Another downgrade to 9.2.2 here. Is this related to 0897d9bee28105cf4bab493344e5d550ffd5a0ba maybe?
Had to downgrade also on my end.
I had to downgrade as well.
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 :(
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
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.
@mech yeah after I fixed that, I noticed it broke node.js, downgrade it is!
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.
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"
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
Same as above. Downgraded to 9.2.2 to fix. Env: Ruby 2 / Rails 4.
@tmcallister I downgraded by quitting the app and copying version 9.2.2 over 9.2.4 without issue.
Thanks @swrobel - had the same issue and downgrading fixed it. Thanks for posting the link!
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.
@stephenalexbrowne your export worked for me... thank you!!
another downgrade here. caused a major headache this evening :cry:
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.
@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
Ran into exact same problems outlined here. Currently sitting back at 9.2.2.0 until this is sorted out.
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.
@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.
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).
Hmm, so I downloaded the source and did my own build. That seemed to have fixed my problems.
@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?
Building it from source worked for me, too. Thanks, @murphyrandle! (Had to do it ...I really like that new retina menu icon....)
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.
same here, reverted to 9.2.2.0
I am reverting to hombrew until a more stable product can be delivered. Please keep me informed.
Is 9.2.2 working fine for you? Or should I go back to default?
+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
So, is anybody maintaining this app still? And thanks for the great answer, @jakob
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
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.
@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
Simply do
sudo ln -s /Library/Postgresql/9.2/lib/libpq.5.dylib /usr/lib/libpq.5.dylib
Vamshi
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)
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.
Beta works for me too.
Seems to be working here too.
Beta version works fine
Beta works for me.
Beta's working fine here too.
Beta works for me too.
Beta works for me too.
@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
.
@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.
I've tried both
gem install pg
andgem 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...