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: (view raw or whole 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/ 
>> 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
jwa(at)bach:helper> otool -L pg_dump
(compatibility version 5.0.0, current version 5.0.0)
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
Kerberos (compatibility version 5.0.0, current version 5.0.0)
(compatibility version 1.0.0, current version 1.2.3)
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
! 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


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-2015 The PostgreSQL Global Development Group