please test these binaries

[Henrik Brautaset Aronsen]

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.

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

H