On 07/01/2009, at 2:42 PM, step21 wrote:
I'll continue with the packaging tomorrow cause it's going to be 5 am soonish, but currently I have the following issues if anyone has a quick thought on one of those. I was under the impression I could use osx-app.sh for native packaging too, but so far: (note: in the paths below /opt/local/ is the macports install path passed to "osx-app.sh" with --libraries) /opt/local/etc/pango/pangox.aliases is not in my macports install (which it tries to copy) so is this a file specific to x11 pango (pango was installed with macports using +no_x11 ofc)
pangox.aliases contains information about the X font set, so if you're not using X11 then I imagine it can just be omitted.
Also the script is looking for: /opt/local/lib/libgtk-x11-2.0.0.dylib /opt/local/lib/libgdk-x11-2.0.0.dylib Only in a native version those would have to be: /opt/local/lib/libgtk-quartz-2.0.0.dylib /opt/local/lib/libgdk-quartz-2.0.0.dylib And so far I'm not quite sure how it gets the impression that it needs the x11 version, at first I thought it was hardcoded in the script, but it's not.
No, none of the dependencies are hardcoded. It determines what they are by recursively calling "otool -L" on the inkscape executable and all the libraries it depends on. Thus, I'd say that if you're seeing this then it means that something didn't compile properly in Macports as +no_x11 and still has the libgtk-x11 library as a dependency. You can probably just use otool yourself to figure out which dependency this is and address the problem.
This is a it strange since the app bundling script should only reference libraries that that copy of Inkscape is linked against -- that is, it shouldn't really be possible for it to reference a non- existent library, or it wouldn't have linked in the first place... unless maybe you have forced removal of a macports package after linking Inkscape. Weird!
Cheers, Michael