Skip site navigation (1) Skip section navigation (2)

Re: wxWidgets alert at start

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 (view raw or flat)
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




In response to

Responses

pgadmin-hackers by date

Next:From: Dave PageDate: 2007-08-02 20:07:08
Subject: Re: Change for connection name
Previous:From: Guillaume LelargeDate: 2007-08-02 15:56:28
Subject: Re: Change for connection name

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group