Debugger, Nested Bundles & @executable_path
От | Florian G. Pflug |
---|---|
Тема | Debugger, Nested Bundles & @executable_path |
Дата | |
Msg-id | 4620EB97.9010704@phlo.org обсуждение исходный текст |
Список | pgadmin-hackers |
Hi I've done a bit of research on the Debugger integration issue on OSX. As it turns out, there is a nearly perfect solution for our problem - with one little downside. There is a macro @loader_path similar to @executeable_path - only that it refers not to path of the top executable that was originally executed, but rather to the path of the image (executable or shared lib) that *actually* needs the library. So simply using @loader_path instead of @executeable_path should make things "Just Work". Sounds too good to be true, doesn't it - well - now that little downside. @loader_path is only supported on OSX 10.4+ :-( grrr... 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 - Shall I go the symlink route, or do we want to consider dropping 10.3 support? It might be acceptable if 10.5 is going to be out by the time 1.8 is released... Any opinions? greetings, Florian Pflug
В списке pgadmin-hackers по дате отправления: