Re: wxWidgets alert at start

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@messiaen:MacOS> cd ../SharedSupport/helper/
>> jwa@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@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@bach:pgadmin3> cd pgAdmin3.app/Contents/SharedSupport/helper/
jwa@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@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@bach:Frameworks> cd ../SharedSupport/helper/
jwa@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