please test these binaries

[Dirk Hohndel]

On Oct 19, 2012, at 1:42 PM, Henrik Brautaset Aronsen wrote:

> Den 19.10.12 22:02, skrev Dirk Hohndel:
>> Dirk Hohndel <dirk at hohndel.org> writes:
>> 
>>> On Oct 19, 2012, at 12:34 AM, Henrik Brautaset Aronsen wrote:
>>> 
>>>> Den 19.10.12 09:26, skrev Henrik Brautaset Aronsen:
>>>>> Oops, just one thing:
>>>>> 
>>>>> $ otool -L /Applications/Subsurface.app/Contents/MacOS/subsurface-bin
>>>>> /Applications/Subsurface.app/Contents/MacOS/subsurface-bin:
>>>>> /Applications/Subsurface.app/Contents/Resources/lib/libxml2.2.dylib (compatibility version 11.0.0, current version 11.0.0)
>>>>>    /Applications/Subsurface.app/Contents/Resources/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
>>>>>    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
>>>>> 
>>>>> The binary links to /Applications/Subsurface.app/... instead of @executable_path/..., so the app will only work if it's placed in the /Applications/ directory.
>>> Funny. I cheated to make all this work correctly - i.e. I built a second copy of MacPorts with /Applications/Subsurface.app/Contents/Resources as prefix to deal with the inability to set the correct gettext search path… and apparently the bundling tool was too smart for its own good and realized that things were already in the "right" directory and didn't replace the absolute locations with relative ones. But that should be easy enough to fix. The exciting news for me is that I now have a path to an actually working, self-contained DMG :-)
>> Would you test again, please? I uploaded a new DMG.
>> 
>> Yet more tweaks to the way I create the DMG should address the
>> issue. Oh, and additional aliases to make more languages work.
> 
> $ otool -L /Applications/Subsurface.app/Contents/MacOS/subsurface-bin
> /Applications/Subsurface.app/Contents/MacOS/subsurface-bin:
>    /opt/local/lib/libxml2.2.dylib (compatibility version 11.0.0, current version 11.0.0)
>    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
>    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
>    /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0)
>    ...
> 
> Ouch.

Wait. WHAT? No… there isn't even an /opt/local install of MacPorts on the machine I built this on.
What on earth is going on. Did I copy the wrong image by mistake when moving things in place on the server?

>> I still cannot figure out how to fix the issue with the Help menu
>> without creating custom .mo files for use on MacOS...
> 
> Yeah, it's annoying.  I don't think it's a blocker for 2.1, though. Could we make a NN_(var) that calls N_(var) for linux and windows, and just returns var for mac?

There are all kind of kludges that we could do. Preferably I'd have us hack on gettext and gtk-mac-integration to fix the stupid bugs instead of working around them…

/D