Re: wxWidgets alert at start

Jyrki Wahlstedt wrote:
> Well,
> this much progress. I built debug version of wxWidgets (2.8.4 with
> separate libraries) and debug version of 1.8.0b2. It crashes, but shows
> something.
> I hope the attachment comes through, but it contains the cause of my
> crash (I hope). For some reason the code fails an assert at arrstr.h
> line 155 nIndex < m_nCount in Item(): wxArrayString leading to index out
> bounds situation leading to crash.
> Of course, this does not mean I can fix it, at least at the moment :-(

Can you attach gdb/xcode at that point and get a backtrace?

Regards, Dave

On 1.8.2007, at 12.31, Dave Page wrote:

> Jyrki Wahlstedt wrote:
>> Well,
>> this much progress. I built debug version of wxWidgets (2.8.4 with
>> separate libraries) and debug version of 1.8.0b2. It crashes, but
>> shows
>> something.
>> I hope the attachment comes through, but it contains the cause of my
>> crash (I hope). For some reason the code fails an assert at arrstr.h
>> line 155 nIndex < m_nCount in Item(): wxArrayString leading to
>> index out
>> bounds situation leading to crash.
>> Of course, this does not mean I can fix it, at least at the
>> moment :-(
>
> Can you attach gdb/xcode at that point and get a backtrace?
>
You mean something like this:
#0 0x90009cd7 in mach_msg_trap ()
#1 0x90009c38 in mach_msg ()
#2 0x9082d2b3 in CFRunLoopRunSpecific ()
#3 0x9082cace in CFRunLoopRunInMode ()
#4 0x92ded8d8 in RunCurrentEventLoopInMode ()
#5 0x92ee2dff in GetNextEventMatchingMask ()
#6 0x92ee2ac0 in WNEInternal ()
#7 0x92ee2a00 in WaitNextEvent ()
#8 0x92f4b7e5 in ModalDialog ()
#9 0x92f4b446 in RunStandardAlert ()
#10 0x106c394e in wxMessageDialog::ShowModal (this=0xbffff110) at ../
src/mac/carbon/msgdlg.cpp:182
#11 0x1067b264 in wxMessageBox (message=(at)0xbffff368,
caption=(at)0xbffff36c, style=538, parent=0x0) at ../src/common/
utilscmn.cpp:1171
#12 0x10727ba8 in wxGUIAppTraitsBase::ShowAssertDialog
(this=0x18d559b0, msg=(at)0xbffff3bc) at ../src/common/appcmn.cpp:599
#13 0x17d232b8 in ShowAssertDialog (szFile=0x30522c, nLine=155,
szFunc=0x18d69f9c, szCond=0x3051e4, szMsg=0x305158,
traits=0x18d559b0) at ../src/common/appbase.cpp:839
#14 0x17d23465 in wxOnAssert (szFile=0x30522c, nLine=155,
szFunc=0x291af8 "Item", szCond=0x3051e4, szMsg=0x305158) at ../src/
common/appbase.cpp:712
#15 0x002e19bd in wxArrayString::Item (this=0xbffff498, nIndex=0)
at ./agent/dlgJob.cpp:154
#16 0x002e2086 in wxArrayString::operator[] (this=0xbffff498,
nIndex=0) at ./agent/dlgSchedule.cpp:161
#17 0x00224ecb in isPgApp (app=(at)0xbffff5f4) at ./utils/misc.cpp:1090
#18 0x00009948 in pgAdmin3::InitPaths (this=0x18d2b990) at ./
pgAdmin3.cpp:766
#19 0x000105ea in pgAdmin3::OnInit (this=0x18d2b990) at ./
pgAdmin3.cpp:206
#20 0x002dfa22 in wxAppConsole::CallOnInit (this=0x18d2b990) at /opt/
local/include/wx-2.8/wx/app.h:76
#21 0x17d68a46 in wxEntry (argc=(at)0x17e60038, argv=0x18d292c0) at ../
src/common/init.cpp:433
#22 0x00007e60 in main (argc=2, argv=0xbffffc3c) at ./pgAdmin3.cpp:104

after 'gdb pgAdmin3 pid'?

!
! 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

Jyrki Wahlstedt wrote:
>
> On 1.8.2007, at 12.31, Dave Page wrote:
>> Can you attach gdb/xcode at that point and get a backtrace?
>>
> You mean something like this:

...

> #17 0x00224ecb in isPgApp (app=(at)0xbffff5f4) at ./utils/misc.cpp:1090
> #18 0x00009948 in pgAdmin3::InitPaths (this=0x18d2b990) at
> ./pgAdmin3.cpp:766
> #19 0x000105ea in pgAdmin3::OnInit (this=0x18d2b990) at ./pgAdmin3.cpp:206
> #20 0x002dfa22 in wxAppConsole::CallOnInit (this=0x18d2b990) at
> /opt/local/include/wx-2.8/wx/app.h:76
> #21 0x17d68a46 in wxEntry (argc=(at)0x17e60038, argv=0x18d292c0) at
> ../src/common/init.cpp:433
> #22 0x00007e60 in main (argc=2, argv=0xbffffc3c) at ./pgAdmin3.cpp:104
>
> after 'gdb pgAdmin3 pid'?

Yup, exactly like that :-)

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). In ~/Library/Preferences/pgadmin3 Preferences,
do you have anything set for the PostgreSQLPath and EnterpriseDBPath
options?

If so, is there a pg_dump executable in either location? What does it
return if you run it with the --version option?

If those locations don't exist, it'll first look in the path for a
pg_dump, and then in a bunch of known locations (straight from the code):

path.Add(wxT("/usr/local/pgsql/bin"));
path.Add(wxT("/usr/local/bin"));
path.Add(wxT("/usr/bin"));
path.Add(wxT("/opt/local/pgsql/bin"));
path.Add(wxT("/opt/local/bin"));
path.Add(wxT("/opt/bin"));

...

path.Add(wxT("/usr/local/enterpriseDB/bin"));
path.Add(wxT("/usr/local/enterprisedb/bin"));
path.Add(wxT("/usr/local/edb/bin"));
path.Add(wxT("/usr/local/bin"));
path.Add(wxT("/usr/bin"));
path.Add(wxT("/opt/local/enterpriseDB/bin"));
path.Add(wxT("/opt/local/enterprisedb/bin"));
path.Add(wxT("/opt/local/edb/bin"));
path.Add(wxT("/opt/local/bin"));

Does it find pg_dump at all? If so, is it returning garbage perhaps?

Regards, Dave

On 1.8.2007, at 13.24, Dave Page wrote:

> Jyrki Wahlstedt wrote:
>>
>> On 1.8.2007, at 12.31, Dave Page wrote:
>>> Can you attach gdb/xcode at that point and get a backtrace?
>>>
>> You mean something like this:
>
> ...
>
>> #17 0x00224ecb in isPgApp (app=(at)0xbffff5f4) at ./utils/misc.cpp:1090
>> #18 0x00009948 in pgAdmin3::InitPaths (this=0x18d2b990) at
>> ./pgAdmin3.cpp:766
>> #19 0x000105ea in pgAdmin3::OnInit (this=0x18d2b990) at ./
>> pgAdmin3.cpp:206
>> #20 0x002dfa22 in wxAppConsole::CallOnInit (this=0x18d2b990) at
>> /opt/local/include/wx-2.8/wx/app.h:76
>> #21 0x17d68a46 in wxEntry (argc=(at)0x17e60038, argv=0x18d292c0) at
>> ../src/common/init.cpp:433
>> #22 0x00007e60 in main (argc=2, argv=0xbffffc3c) at ./pgAdmin3.cpp:
>> 104
>>
>> after 'gdb pgAdmin3 pid'?
>
> Yup, exactly like that :-)
>
> 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). In ~/Library/Preferences/pgadmin3
> Preferences,
> do you have anything set for the PostgreSQLPath and EnterpriseDBPath
> options?
Portion of preferences:
PostgreSQLPath=/Apps/pgAdmin3.app/Contents/SharedSupport/helper
EnterpriseDBPath=

>
> 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
>
> If those locations don't exist, it'll first look in the path for a
> pg_dump, and then in a bunch of known locations (straight from the
> code):
>
<snip>
The referenced library seems to exist, where it is supposed to be:
jwa(at)messiaen:Frameworks> ll
total 479752
-rwxr-xr-x 2 root admin 454260 1 Elo 12:11 libSDL-1.2.0.dylib*
-rwxr-xr-x 2 root admin 1394844 1 Elo 12:11 libcrypto.
0.9.8.dylib*
-rwxr-xr-x 2 root admin 1053388 1 Elo 12:11 libiconv.2.dylib*
-rwxr-xr-x 2 root admin 279152 1 Elo 12:11 libncurses.5.dylib*
-rwxr-xr-x 2 root admin 116004 1 Elo 12:11 libpq.5.dylib*
-rwxr-xr-x 2 root admin 452148 1 Elo 12:11 libreadline.
5.2.dylib*
-rwxr-xr-x 2 root admin 283320 1 Elo 12:11 libssl.0.9.8.dylib*
...

The other pg_dump gives:
jwa(at)messiaen:Frameworks> /opt/local/lib/postgresql82/bin/pg_dump --
version
pg_dump (PostgreSQL) 8.2.4

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. This comes from the lines in
config.log:
configure:6183: gcc -o conftest -O2 -I/opt/local/include -L/opt/local/
lib -L/opt/local/lib/postgresql82/lib conftest.c -lpq >&5
/usr/bin/ld: warning -L: directory name (/opt/local/lib/postgresql82/
lib) does not exist
/usr/bin/ld: can't locate file for: -lpq
collect2: ld returned 1 exit status

For some reason it seems that 'lib' is attached to the directory name
given by pg_config:
jwa(at)messiaen:pgAdmin3> pg_config --libdir
/opt/local/lib/postgresql82
jwa(at)messiaen:pgAdmin3> ls $(pg_config --libdir)
adminpack.so* libpq.a
ascii_and_mic.so* libpq.dylib@
bin/ lo.so*
cyrillic_and_mic.so* pg_buffercache.so*
dblink.so* pg_trgm.so*
euc_cn_and_mic.so* pgxml.so*
euc_jp_and_sjis.so* pgxs/
euc_kr_and_mic.so* plpgsql.so*
euc_tw_and_big5.so* plpython.so*
fuzzystrmatch.so* slony1_funcs.so*
latin2_and_win1250.so* tsearch2.so*
latin_and_mic.so* utf8_and_ascii.so*
libecpg.5.2.dylib* utf8_and_big5.so*
libecpg.5.dylib@ utf8_and_cyrillic.so*
libecpg.a utf8_and_euc_cn.so*
libecpg.dylib@ utf8_and_euc_jp.so*
libecpg_compat.2.2.dylib* utf8_and_euc_kr.so*
libecpg_compat.2.dylib@ utf8_and_euc_tw.so*
libecpg_compat.a utf8_and_gb18030.so*
libecpg_compat.dylib@ utf8_and_gbk.so*
libpgport.a utf8_and_iso8859.so*
libpgtypes.2.2.dylib* utf8_and_iso8859_1.so*
libpgtypes.2.dylib@ utf8_and_johab.so*
libpgtypes.a utf8_and_sjis.so*
libpgtypes.dylib@ utf8_and_uhc.so*
libpq.5.0.dylib* utf8_and_win.so*
libpq.5.dylib@ xxid.so*

Well, sorry for this long and confused mess, but one could say there
is hope to find the solution.
> Regards, 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

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.

>>
>> 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.

> 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.

Thansk, Dave.

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

Jyrki Wahlstedt wrote:
> Hmm, I'm not sure, whether the situation improved. What happens is that
> the app crashes twice. I wouldn't bet it is better :-)

OK, last time I checked once an app had crashed it couldn't crash again
unless it was restarted!! What happens *exactly*, including error
message text?

> 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

OK, but what if you then run otool on each of those libs that are in the
bundle? Perhaps one of them is referencing something thats not there (or
the build script broke a reference).

> 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).

That works OK for me. It's just checking for the symbol in the lib which
is only there if it's linked with openssl (whether or not it's an
imported or exported symbol isn't relevant to us - just whether it's there).

Regards, Dave

On 2.8.2007, at 23.20, Dave Page wrote:

> Jyrki Wahlstedt wrote:
>> Hmm, I'm not sure, whether the situation improved. What happens is
>> that
>> the app crashes twice. I wouldn't bet it is better :-)
>
> OK, last time I checked once an app had crashed it couldn't crash
> again
> unless it was restarted!! What happens *exactly*, including error
> message text?
>
Ok, I could hardly believe my eyes with this. After 'make install' I
write the command 'open pgAdmin3.app', after a while I get wxWidgets
debug alert, identical to the one I had previously. An instant later
I get the crashdump dialog about unexpected quit, and if I choose
'Report…', I get this:
Thread 0 Crashed:
0 org.postgresql.pgadmin 0x0022638d isPgApp(wxString
const&) + 189 (misc.cpp:1098)
1 org.postgresql.pgadmin 0x00009d60 pgAdmin3::InitPaths()
+ 4342 (pgAdmin3.cpp:766)
2 org.postgresql.pgadmin 0x00010a02 pgAdmin3::OnInit() +
704 (pgAdmin3.cpp:208)
3 org.postgresql.pgadmin 0x002e0f0a
wxAppConsole::CallOnInit() + 24 (app.h:76)
4 ...x_base_carbonud-2.8.0.dylib 0x17d65a46 wxEntry(int&,
wchar_t**) + 52 (init.cpp:433)
5 org.postgresql.pgadmin 0x00008278 main + 24
(pgAdmin3.cpp:104)
6 org.postgresql.pgadmin 0x00007b76 _start + 216
7 org.postgresql.pgadmin 0x00007a9d start + 41

and an instant later:
Thread 0 Crashed:
0 ...x_base_carbonud-2.8.0.dylib 0x17d85bdd wxStringBase::find
(wxStringBase const&, unsigned long) const + 23 (string.h:412)
1 ...x_base_carbonud-2.8.0.dylib 0x17d8753c wxStringBase::find
(wchar_t const*, unsigned long, unsigned long) const + 62 (string.cpp:
495)
2 ...x_base_carbonud-2.8.0.dylib 0x17d875c2 wxString::Find(wchar_t
const*) const + 40 (string.cpp:1681)
3 org.postgresql.pgadmin 0x002eb03e wxString::Contains
(wxString const&) const + 32 (pgConn.cpp:1272)
4 org.postgresql.pgadmin 0x002263b1 isPgApp(wxString
const&) + 225 (misc.cpp:1098)
5 org.postgresql.pgadmin 0x00009d60 pgAdmin3::InitPaths()
+ 4342 (pgAdmin3.cpp:766)
6 org.postgresql.pgadmin 0x00010a02 pgAdmin3::OnInit() +
704 (pgAdmin3.cpp:208)
7 org.postgresql.pgadmin 0x002e0f0a
wxAppConsole::CallOnInit() + 24 (app.h:76)
8 ...x_base_carbonud-2.8.0.dylib 0x17d65a46 wxEntry(int&,
wchar_t**) + 52 (init.cpp:433)
9 org.postgresql.pgadmin 0x00008278 main + 24
(pgAdmin3.cpp:104)
10 org.postgresql.pgadmin 0x00007b76 _start + 216
11 org.postgresql.pgadmin 0x00007a9d start + 41

I shouldn't have said that the app crashed twice, but superficially
it looks something like that.
>
>> 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
>
> OK, but what if you then run otool on each of those libs that are
> in the
> bundle? Perhaps one of them is referencing something thats not
> there (or
> the build script broke a reference).
Here's the output:
jwa(at)bach:Frameworks> for l in libcrypto.0.9.8.dylib libpq.5.dylib
libreadline.5.2.dylib libssl.0.9.8.dylib libz.1.dylib ; do
> echo $l
> otool -L $l
> done
libcrypto.0.9.8.dylib
libcrypto.0.9.8.dylib:
libcrypto.0.9.8.dylib (compatibility version 0.9.8, current
version 0.9.8)
@executable_path/../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libpq.5.dylib
libpq.5.dylib:
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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libreadline.5.2.dylib
libreadline.5.2.dylib:
libreadline.5.2.dylib (compatibility version 5.0.0, current
version 5.2.0)
@executable_path/../../Contents/Frameworks/libncurses.
5.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
libssl.0.9.8.dylib
libssl.0.9.8.dylib:
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)
@executable_path/../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libz.1.dylib
libz.1.dylib:
libz.1.dylib (compatibility version 1.0.0, current version
1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
jwa(at)bach:Frameworks>

I then copied the /opt/local/lib libraries over and verified that the
app works. I looked at otool output:
jwa(at)bach:Oddlibs> otool -L libpq.5.dylib ../Frameworks/libpq.5.dylib
libpq.5.dylib:
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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
../Frameworks/libpq.5.dylib:
/opt/local/lib/postgresql82/libpq.5.dylib (compatibility
version 5.0.0, current version 5.0.0)
/opt/local/lib/libssl.0.9.8.dylib (compatibility version
0.9.8, current version 0.9.8)
/opt/local/lib/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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)

The same output from your build is:
jwa(at)bach:Frameworks> otool -L libpq.5.dylib
libpq.5.dylib:
libpq.5.dylib (compatibility version 5.0.0, current version
5.0.0)
/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)

There are minor differences, but at least I can't see anything
significant.
>
>> 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).
>
> That works OK for me. It's just checking for the symbol in the lib
> which
> is only there if it's linked with openssl (whether or not it's an
> imported or exported symbol isn't relevant to us - just whether
> it's there).
>
> Regards, Dave

Thanks for the clarification!

!
! 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

I soon get used to the fact that I changed my subscriber email,
setting it right helps in getting the message through. If this is a
double, feel free to erase this (as always)!

On 2.8.2007, at 23.20, Dave Page wrote:

> Jyrki Wahlstedt wrote:
>> Hmm, I'm not sure, whether the situation improved. What happens is
>> that
>> the app crashes twice. I wouldn't bet it is better :-)
>
> OK, last time I checked once an app had crashed it couldn't crash
> again
> unless it was restarted!! What happens *exactly*, including error
> message text?
>
Ok, I could hardly believe my eyes with this. After 'make install' I
write the command 'open pgAdmin3.app', after a while I get wxWidgets
debug alert, identical to the one I had previously. An instant later
I get the crashdump dialog about unexpected quit, and if I choose
'Report…', I get this:
Thread 0 Crashed:
0 org.postgresql.pgadmin 0x0022638d isPgApp(wxString
const&) + 189 (misc.cpp:1098)
1 org.postgresql.pgadmin 0x00009d60 pgAdmin3::InitPaths()
+ 4342 (pgAdmin3.cpp:766)
2 org.postgresql.pgadmin 0x00010a02 pgAdmin3::OnInit() +
704 (pgAdmin3.cpp:208)
3 org.postgresql.pgadmin 0x002e0f0a
wxAppConsole::CallOnInit() + 24 (app.h:76)
4 ...x_base_carbonud-2.8.0.dylib 0x17d65a46 wxEntry(int&,
wchar_t**) + 52 (init.cpp:433)
5 org.postgresql.pgadmin 0x00008278 main + 24
(pgAdmin3.cpp:104)
6 org.postgresql.pgadmin 0x00007b76 _start + 216
7 org.postgresql.pgadmin 0x00007a9d start + 41

and an instant later:
Thread 0 Crashed:
0 ...x_base_carbonud-2.8.0.dylib 0x17d85bdd wxStringBase::find
(wxStringBase const&, unsigned long) const + 23 (string.h:412)
1 ...x_base_carbonud-2.8.0.dylib 0x17d8753c wxStringBase::find
(wchar_t const*, unsigned long, unsigned long) const + 62 (string.cpp:
495)
2 ...x_base_carbonud-2.8.0.dylib 0x17d875c2 wxString::Find(wchar_t
const*) const + 40 (string.cpp:1681)
3 org.postgresql.pgadmin 0x002eb03e wxString::Contains
(wxString const&) const + 32 (pgConn.cpp:1272)
4 org.postgresql.pgadmin 0x002263b1 isPgApp(wxString
const&) + 225 (misc.cpp:1098)
5 org.postgresql.pgadmin 0x00009d60 pgAdmin3::InitPaths()
+ 4342 (pgAdmin3.cpp:766)
6 org.postgresql.pgadmin 0x00010a02 pgAdmin3::OnInit() +
704 (pgAdmin3.cpp:208)
7 org.postgresql.pgadmin 0x002e0f0a
wxAppConsole::CallOnInit() + 24 (app.h:76)
8 ...x_base_carbonud-2.8.0.dylib 0x17d65a46 wxEntry(int&,
wchar_t**) + 52 (init.cpp:433)
9 org.postgresql.pgadmin 0x00008278 main + 24
(pgAdmin3.cpp:104)
10 org.postgresql.pgadmin 0x00007b76 _start + 216
11 org.postgresql.pgadmin 0x00007a9d start + 41

I shouldn't have said that the app crashed twice, but superficially
it looks something like that.
>
>> 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
>
> OK, but what if you then run otool on each of those libs that are
> in the
> bundle? Perhaps one of them is referencing something thats not
> there (or
> the build script broke a reference).
Here's the output:
jwa(at)bach:Frameworks> for l in libcrypto.0.9.8.dylib libpq.5.dylib
libreadline.5.2.dylib libssl.0.9.8.dylib libz.1.dylib ; do
> echo $l
> otool -L $l
> done
libcrypto.0.9.8.dylib
libcrypto.0.9.8.dylib:
libcrypto.0.9.8.dylib (compatibility version 0.9.8, current
version 0.9.8)
@executable_path/../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libpq.5.dylib
libpq.5.dylib:
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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libreadline.5.2.dylib
libreadline.5.2.dylib:
libreadline.5.2.dylib (compatibility version 5.0.0, current
version 5.2.0)
@executable_path/../../Contents/Frameworks/libncurses.
5.dylib (compatibility version 5.0.0, current version 5.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
libssl.0.9.8.dylib
libssl.0.9.8.dylib:
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)
@executable_path/../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libz.1.dylib
libz.1.dylib:
libz.1.dylib (compatibility version 1.0.0, current version
1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
jwa(at)bach:Frameworks>

I then copied the /opt/local/lib libraries over and verified that the
app works. I looked at otool output:
jwa(at)bach:Oddlibs> otool -L libpq.5.dylib ../Frameworks/libpq.5.dylib
libpq.5.dylib:
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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
../Frameworks/libpq.5.dylib:
/opt/local/lib/postgresql82/libpq.5.dylib (compatibility
version 5.0.0, current version 5.0.0)
/opt/local/lib/libssl.0.9.8.dylib (compatibility version
0.9.8, current version 0.9.8)
/opt/local/lib/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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)

The same output from your build is:
jwa(at)bach:Frameworks> otool -L libpq.5.dylib
libpq.5.dylib:
libpq.5.dylib (compatibility version 5.0.0, current version
5.0.0)
/usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)

There are minor differences, but at least I can't see anything
significant.
>
>> 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).
>
> That works OK for me. It's just checking for the symbol in the lib
> which
> is only there if it's linked with openssl (whether or not it's an
> imported or exported symbol isn't relevant to us - just whether
> it's there).
>
> Regards, Dave

Thanks for the clarification!

!
! 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

On 3.8.2007, at 0.15, Jyrki Wahlstedt wrote:

> I soon get used to the fact that I changed my subscriber email,
> setting it right helps in getting the message through. If this is a
> double, feel free to erase this (as always)!
>
> On 2.8.2007, at 23.20, Dave Page wrote:
>
>> Jyrki Wahlstedt wrote:
>>> Hmm, I'm not sure, whether the situation improved. What happens
>>> is that
>>> the app crashes twice. I wouldn't bet it is better :-)
>>
>> OK, last time I checked once an app had crashed it couldn't crash
>> again
>> unless it was restarted!! What happens *exactly*, including error
>> message text?
>>
<a lot snipped>

Here's what I can do: in building the bundle I can replace the helper
apps (pg_dump, pg_dumpall, pg_restore) with symbolic links to the
respective apps in the postgresql82 port, as those apps are sure to
exist due to the dependency setting. I made that replacement
manually, and now pgAdmin starts ok. I don't like to mess with the
internals of an app, but I don't like crashing either:-) How does
that sound? It is relatively easy to write, and easy to remove, if
and when a solution is found to the problem.
PS It would help if someone else would try to use MacPorts, too, to
try to reproduce what I described in my previous messages, I would
like to be wrong (I've attached my Portfile).

Jyrki Wahlstedt wrote:
>
> On 3.8.2007, at 0.15, Jyrki Wahlstedt wrote:
>
>> I soon get used to the fact that I changed my subscriber email,
>> setting it right helps in getting the message through. If this is a
>> double, feel free to erase this (as always)!
>>
>> On 2.8.2007, at 23.20, Dave Page wrote:
>>
>>> Jyrki Wahlstedt wrote:
>>>> Hmm, I'm not sure, whether the situation improved. What happens is that
>>>> the app crashes twice. I wouldn't bet it is better :-)
>>>
>>> OK, last time I checked once an app had crashed it couldn't crash again
>>> unless it was restarted!! What happens *exactly*, including error
>>> message text?
>>>
> <a lot snipped>
>
> Here's what I can do: in building the bundle I can replace the helper
> apps (pg_dump, pg_dumpall, pg_restore) with symbolic links to the
> respective apps in the postgresql82 port, as those apps are sure to
> exist due to the dependency setting. I made that replacement manually,
> and now pgAdmin starts ok. I don't like to mess with the internals of an
> app, but I don't like crashing either:-) How does that sound? It is
> relatively easy to write, and easy to remove, if and when a solution is
> found to the problem.

Well that will work (and does make it sound like something is foobarred
when we create the bundle), but what exactly are you trying to achieve?

I assume you're not just trying to use pgAdmin, otherwise why not just
use the bundle I provide which you said works OK?

If you want to hack on pgAdmin, then pkg/mac/debug-bundle.sh will create
a symlink pseudo-bundle which doesn't need to be rebuilt every time you
recompile.

Regards, Dave

Dave Page wrote:
> Jyrki Wahlstedt wrote:
>>
>> On 3.8.2007, at 0.15, Jyrki Wahlstedt wrote:
>>
>>> I soon get used to the fact that I changed my subscriber email, setting
>>> it right helps in getting the message through. If this is a double, feel
>>> free to erase this (as always)!
>>>
>>> On 2.8.2007, at 23.20, Dave Page wrote:
>>>
>>>> Jyrki Wahlstedt wrote:
>>>>> Hmm, I'm not sure, whether the situation improved. What happens is
>>>>> that the app crashes twice. I wouldn't bet it is better :-)
>>>>
>>>> OK, last time I checked once an app had crashed it couldn't crash again
>>>> unless it was restarted!! What happens *exactly*, including error
>>>> message text?
>>>>
>> <a lot snipped>
>>
>> Here's what I can do: in building the bundle I can replace the helper apps
>> (pg_dump, pg_dumpall, pg_restore) with symbolic links to the respective
>> apps in the postgresql82 port, as those apps are sure to exist due to the
>> dependency setting. I made that replacement manually, and now pgAdmin
>> starts ok. I don't like to mess with the internals of an app, but I don't
>> like crashing either:-) How does that sound? It is relatively easy to
>> write, and easy to remove, if and when a solution is found to the problem.
>
> Well that will work (and does make it sound like something is foobarred when
> we create the bundle), but what exactly are you trying to achieve?

Think I found the foobarization...

This is what I wrote in one of the threads dealing with debugger integration
(Back when it looked like it'd be a seperate executeable):

----------------------
The only alternative I see is to symlink
Contents/Resources/Debugger.app/Contents/Frameworks to Contents/Frameworks,
and to run complete-bundle.sh twice - once for the main app, and once
for the Debugger (Running it twice isn't stricly needed, but it seems to
be cleaner). The major downside of this is that we we currently do isn't
only broken (in pratice) for the Debugger, but also (in theory) for
pg_dump and friends. It only works because libpq doesn't have any dependencies
that live inside the pgadmin bundle. :-(
-----------------------

So I least at that point I was aware that we are walking on thin ice with
how we integrate pg_dump and friends into the bundle. Seems that using a
version of libpq that doesn't link to the system provided libssl, but to a
custom version instead (and thereby breaking that "doesn't have dependencies
that live inside the pgadmin bundle" assumtion)is enough to let the ice break.

The only really correct fix would be to use @loader_path instead of
@executable_path when referencing shared libraries (@loader_path is the
path of the image *requireing* the lib, instead of the top-level executable) -
but that means dropping support for 10.3 :-(. One alternative that I can see is
to put pg_dump and friends into Contents/SharedSupport directly - that way,
the relative path from pg_dump to Contents/Frameworks is that same as for
main pgAdmin executeable (which lives in Contents/MacOS). Not exactly pretty,
but hey, who looks into the bundle anyway?

Or we decide that whoever builds custom pgAdmin bundles needs to be carefull
not to use a version of libpq that depends on other non-system shared libraries.

greetings, Florian Pflug

On 4.8.2007, at 13.29, Dave Page wrote:

> Jyrki Wahlstedt wrote:
>> On 3.8.2007, at 0.15, Jyrki Wahlstedt wrote:
<snip>
>> Here's what I can do: in building the bundle I can replace the
>> helper apps (pg_dump, pg_dumpall, pg_restore) with symbolic links
>> to the respective apps in the postgresql82 port, as those apps are
>> sure to exist due to the dependency setting. I made that
>> replacement manually, and now pgAdmin starts ok. I don't like to
>> mess with the internals of an app, but I don't like crashing
>> either:-) How does that sound? It is relatively easy to write, and
>> easy to remove, if and when a solution is found to the problem.
>
> Well that will work (and does make it sound like something is
> foobarred when we create the bundle), but what exactly are you
> trying to achieve?

I'm maintaining pgAdmin package in MacPorts, packaging system for OS
X modeled initially after FreeBSD ports collection. Hence I'd like to
be able to build the app from sources, and if there are problems in
that, I try to get them solved. The build process should co-operate
with the dependencies, built similarly. The first version in MacPorts
(at the time DarwinPorts) was 1.4, all versions so far have been
without problems.
>
> I assume you're not just trying to use pgAdmin, otherwise why not
> just use the bundle I provide which you said works OK?
>
> If you want to hack on pgAdmin, then pkg/mac/debug-bundle.sh will
> create a symlink pseudo-bundle which doesn't need to be rebuilt
> every time you recompile.
>
Thanks for the tip, I'm always happy to learn new things!

> Regards, 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

Florian G. Pflug wrote:
>
> Think I found the foobarization...

Agreed.

> So I least at that point I was aware that we are walking on thin ice with
> how we integrate pg_dump and friends into the bundle. Seems that using a
> version of libpq that doesn't link to the system provided libssl, but to
> a custom version instead (and thereby breaking that "doesn't have
> dependencies
> that live inside the pgadmin bundle" assumtion)is enough to let the ice
> break.

Or any library not directly linked to the executable itself.

> The only really correct fix would be to use @loader_path instead of
> @executable_path when referencing shared libraries (@loader_path is the
> path of the image *requireing* the lib, instead of the top-level
> executable) -
> but that means dropping support for 10.3 :-(.

Yeah, I'm not sure we should do that just yet.

> One alternative that I can
> see is
> to put pg_dump and friends into Contents/SharedSupport directly - that way,
> the relative path from pg_dump to Contents/Frameworks is that same as for
> main pgAdmin executeable (which lives in Contents/MacOS). Not exactly
> pretty,
> but hey, who looks into the bundle anyway?

:-)

Jyrki; the attached patch should implement what Florian is suggesting -
can you test it please? Make sure you run the bootstrap script, and to
be on the safe side, remove your preferences file as well.

Thanks, Dave

On 6.8.2007, at 13.47, Dave Page wrote:

> Florian G. Pflug wrote:
>>
>> Think I found the foobarization...
>
> Agreed.
>
>> So I least at that point I was aware that we are walking on thin
>> ice with
>> how we integrate pg_dump and friends into the bundle. Seems that
>> using a
>> version of libpq that doesn't link to the system provided libssl,
>> but to
>> a custom version instead (and thereby breaking that "doesn't have
>> dependencies
>> that live inside the pgadmin bundle" assumtion)is enough to let
>> the ice
>> break.
>
> Or any library not directly linked to the executable itself.
>
>> The only really correct fix would be to use @loader_path instead of
>> @executable_path when referencing shared libraries (@loader_path
>> is the
>> path of the image *requireing* the lib, instead of the top-level
>> executable) -
>> but that means dropping support for 10.3 :-(.
>
> Yeah, I'm not sure we should do that just yet.
>
>> One alternative that I can
>> see is
>> to put pg_dump and friends into Contents/SharedSupport directly -
>> that way,
>> the relative path from pg_dump to Contents/Frameworks is that same
>> as for
>> main pgAdmin executeable (which lives in Contents/MacOS). Not exactly
>> pretty,
>> but hey, who looks into the bundle anyway?
>
> :-)
>
> Jyrki; the attached patch should implement what Florian is
> suggesting -
> can you test it please? Make sure you run the bootstrap script, and to
> be on the safe side, remove your preferences file as well.
>
> Thanks, Dave
<patch snipped>
Hi,
I was and I suppose you are very happy that now everything seems to
be working again! Thank you a lot and very much and million times!
Solving this problem was not straightforward…

PS I didn't remove the preferences (seems that I like to take risks
now and then:-).
!
! 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

Jyrki Wahlstedt wrote:
>
> Hi,
> I was and I suppose you are very happy that now everything seems to be
> working again! Thank you a lot and very much and million times! Solving
> this problem was not straightforward…

You're welcome - thanks for helping get it sorted.

> PS I didn't remove the preferences (seems that I like to take risks now
> and then:-).

:-)

Regards, Dave

Jyrki Wahlstedt wrote:
>
> On 4.8.2007, at 13.29, Dave Page wrote:
>
>> Jyrki Wahlstedt wrote:
>>> On 3.8.2007, at 0.15, Jyrki Wahlstedt wrote:
> <snip>
>>> Here's what I can do: in building the bundle I can replace the helper
>>> apps (pg_dump, pg_dumpall, pg_restore) with symbolic links to the
>>> respective apps in the postgresql82 port, as those apps are sure to
>>> exist due to the dependency setting. I made that replacement
>>> manually, and now pgAdmin starts ok. I don't like to mess with the
>>> internals of an app, but I don't like crashing either:-) How does
>>> that sound? It is relatively easy to write, and easy to remove, if
>>> and when a solution is found to the problem.
>>
>> Well that will work (and does make it sound like something is
>> foobarred when we create the bundle), but what exactly are you trying
>> to achieve?
>
> I'm maintaining pgAdmin package in MacPorts, packaging system for OS X
> modeled initially after FreeBSD ports collection. Hence I'd like to be
> able to build the app from sources, and if there are problems in that, I
> try to get them solved. The build process should co-operate with the
> dependencies, built similarly. The first version in MacPorts (at the
> time DarwinPorts) was 1.4, all versions so far have been without problems.

In that case (Disclaimer: I don't know about MacPorts - I just assume that
it works kind of like fink), you might be interested in skipping
complete-bundle.sh completly for your build. The current build infrastructure
for pgadmin on OSX tries to create a relocateable bundle, because this is
how most OSX sofware is distributed. But I think that doesn't fit very well
with the idea of a package manager (if indeed MacPorts is something like that).

For example, you'd needlessly copy the full wx libs into the bundle - which
do don't need to do, if you can just mark pgadmin as depending on
wx (and the wx libs are at a known place).

Sadly, you can'd just ignore that whole bundle issue completly - the window
management on OSX for non-bundle apps is very strange (You get a lot of
funny effects, like a window that you can see, but that never gets the focus,
no matter how hard you try to click it). But you really only need the pgAdmin
binary, the Info.plist file, and the PkgInfo file for OSX to be happy. The
other libs (wx, libxslt maybe, and libpq) could reside wherever MacPorts
wants them to.

greetings, Florian Pflug