On 2.8.2007, at 12.21, Dave Page wrote:
Jyrki Wahlstedt wrote:
It's dying when it checks for the PostgreSQL utilities (isPgApp()
runs a
utility with the --version option to check that it's a PostgreSQL
util,
and not an EDB version).
I've committed a fix to SVN trunk that should give an error and
continue
gracefully if the version check cannot be completed. In your case, I
would expect this to now just throw an error at startup, then continue
as normal. Please test.
Hmm, I'm not sure, whether the situation improved. What happens is
that the app crashes twice. I wouldn't bet it is better :-)
If so, is there a pg_dump executable in either location? What
does it
return if you run it with the --version option?
[EMAIL PROTECTED]:MacOS> cd ../SharedSupport/helper/
[EMAIL PROTECTED]:helper> ll
total 728
-rwxr-xr-x 2 root admin 215632 1 Elo 12:11 pg_dump*
-rwxr-xr-x 2 root admin 54892 1 Elo 12:11 pg_dumpall*
-rwxr-xr-x 2 root admin 96532 1 Elo 12:11 pg_restore*
[EMAIL PROTECTED]:helper> ./pg_dump --version
dyld: Library not loaded:
@executable_path/../../Contents/Frameworks/libssl.0.9.8.dylib
Referenced from:
/Applications/MacPorts/pgAdmin3.app/Contents/SharedSupport/
helper/./../../../Contents/Frameworks/libpq.5.dylib
Reason: image not found
Trace/BPT trap
So, pg_dump exists, but doesnt return anything that makes sense
(and it
is not found anywhere else
OK, thats wierd. Can you dig around in the pg_dump executable and the
libraries it references within the bundle to try to track down if the
path munging that happens during bundle creation has gone wrong
please?
Use 'otool -L <exe or lib>' to get a list of libraries and the paths
that they each think they're using.
In cases like this I'm always inclined to think that I myself have
done something stupid. Now I just don't know what it could be. The
output from SharedSupport/helper/pg_dump is:
[EMAIL PROTECTED]:pgadmin3> cd pgAdmin3.app/Contents/SharedSupport/helper/
[EMAIL PROTECTED]:helper> otool -L pg_dump
pg_dump:
@executable_path/../../../Contents/Frameworks/libpq.5.dylib
(compatibility version 5.0.0, current version 5.0.0)
@executable_path/../../../Contents/Frameworks/libssl.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
@executable_path/../../../Contents/Frameworks/libcrypto.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/System/Library/Frameworks/Kerberos.framework/Versions/A/
Kerberos (compatibility version 5.0.0, current version 5.0.0)
@executable_path/../../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
@executable_path/../../../Contents/Frameworks/libreadline.
5.2.dylib (compatibility version 5.0.0, current version 5.2.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
Looks ok to me, though I then deleted the above libraries from
Frameworks and copied the ones used by MacPorts postgresql82 port
pg_dump, and:
[EMAIL PROTECTED]:Frameworks> sudo cp /opt/local/lib/postgresql82/libpq.
5.dylib /opt/local/lib/libssl.0.9.8.dylib /opt/local/lib/libcrypto.
0.9.8.dylib /opt/local/lib/libz.1.dylib /opt/local/lib/libreadline.
5.2.dylib .
[EMAIL PROTECTED]:Frameworks> cd ../SharedSupport/helper/
[EMAIL PROTECTED]:helper> ./pg_dump --version
pg_dump (PostgreSQL) 8.2.4
There seems then to be something with the libraries (the otool out of
SharedSupport/helper/pg_dump remaining the same), I just haven't
figured out what.
Ok, I dug around a bit, and it seems that the use of pg_config is not
totally proper in the configuration phase (I must admit that MacPorts
PostgreSQL directory structure is not too simple either, but
pg_config
should be able to take care of that). Because of this I have made
symbolic links in the build structure, but that shouldn't be
needed, as
pg_config should tell all necessary information. I tried to use
purely
pg_config, but could not configure, because no valid PostgreSQL
installation was found.
I've committed a fix to acinclude.m4 that removes two places where we
assume $PGLIB == $PGHOME/lib (we get the value from pg_config now,
as we
should. Can you test it please? You'll need to re-run the bootstrap
script after you svn update.
The configure phase behaves now well, as expected. Thanks! There is,
however, one slightly odd thing. In the summary there is a statement
telling that SSL support is missing based probably on:
checking for SSL_connect in -lpq... no
checking for krb5_free_principal in -lpq... no
This is certainly true in a way, as those symbols are not defined in
libpq, but in libssl and libkrb5, respectively, but they do exist,
both libraries and symbols (checked with nm -g).
Thansk, Dave.
!
! Jyrki Wahlstedt
! http://www.wahlstedt.fi/jyrki/
!
! Our life is no dream; but it ought to become one and perhaps will.
! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780
6366 EFD9 139C C386
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
