From: | Jyrki Wahlstedt <jyrki(dot)wahlstedt(at)hut(dot)fi> |
---|---|
To: | Dave Page <dpage(at)postgresql(dot)org> |
Cc: | pgadmin-hackers(at)postgresql(dot)org |
Subject: | Re: wxWidgets alert at start |
Date: | 2007-08-02 18:47:46 |
Message-ID: | BC3A06D0-41B7-4ED3-80B5-F236E700AC45@hut.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
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?
>> jwa(at)messiaen:MacOS> cd ../SharedSupport/helper/
>> jwa(at)messiaen: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*
>> jwa(at)messiaen: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:
jwa(at)bach:pgadmin3> cd pgAdmin3.app/Contents/SharedSupport/helper/
jwa(at)bach: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:
jwa(at)bach: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 .
jwa(at)bach:Frameworks> cd ../SharedSupport/helper/
jwa(at)bach: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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2007-08-02 20:07:08 | Re: Change for connection name |
Previous Message | Guillaume Lelarge | 2007-08-02 15:56:28 | Re: Change for connection name |