Re: wxWidgets alert at start

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