![](https://secure.gravatar.com/avatar/789edbb3a9b9f3f13815d199bfa4c81b.jpg?s=120&d=mm&r=g)
On 21/3/10 15:33, Stuart Edwards wrote:
Update on the Aqua Intel packaging saga. Not a direct request for help (but it's always welcome) - more of an fyi.
No success yet, but some incremental progress.
The 50 char requirement for the path to Macports was puzzling based on Wolf's statement that he used a short one. But it was definitely where osx-app.sh was failing. So on the theory of 'if in doubt, leave it out' I commented out all the offending lines (468-471 and 473-482) which basically just leaves the 'rewritelibpaths' instruction with no conditions. This runs ok and after an hour of rewriting dylib paths (actually three times before I got it to complete the task) we reach the next hurdle.
This will not work. Please undo all your changes to osx-app.sh and do as the script tells you if it fails to rewrite the paths to the linked shared libs: after building Inkscape.app, edit 'Inkscape.app/Contents/Resources/bin/inkscape' and uncomment the line with 'DYLD_LIBRARY_PATH' as told by the error message.
Applying the rewritelibpaths{} function when the linked shared libs have been built with a shorter pathname (i.e. MacPorts default prefix '/opt/local') will fail, if not during rewriting then at runtime.
If you really want to create Inkscape.app with the all lib paths rewritten you have to start from scratch and completely rebuild your MacPorts tree after installing MacPorts itself from source with a custom prefix - just as Michael explained in his earlier answer.
osx-app.sh exits back to osx-build.sh and I'm presented with the error: 'head: ../../.svn/entries: No such file or directory' This originates at line 268 which my almost non-existent bash scripting skills are unable to decipher.
ignore the warning about missing svn entries, IIRC it's not critical at this stage.
It doesn't look too critical at this stage of the game, so since the next subroutine calls osx-dmg.sh to assemble the dmg bundle - I try that as a standalone script: './osx-dmg.sh -p "Inkscape.app" ' That runs ok and creates a dmg. Unfortunately the Inkscape.app is broken - in retrospect I should have caught that by looking at the icon in the packaging/macosx directory. The dmg is 136.4 Mb and the app is 435 Mb which looks about right so we must be getting close.
I would recommend to do one step at a time only. Why build a DMG if you don't have a working Inkscape.app yet?
One difference I notice in the contents of Inkscape.app compared to my X11 build is that Contents/MacOS is empty in the aqua build and contains a small (45kb) executable (called inkscape) in the X11 build. Executing this file opens the application, so clearly it's a critical element.
The application will not start if the launcher binary is missing. I don't know what went wrong - you should have seen related error messages in the output from osx-build.sh.
I'd be interested to know how Inkscape.app determines whether it's broken or not (how does it know to put the 'no entry' sign on the icon?) - is there some sort of audit process that compares the content with a defined contents list? Also, at what point is Contents/MacOSX/inkscape file created?
It is the first thing that's built when running
$ osx-build.sh p -py /path/to/Python-packages
and the output of this process is usually very verbose ;)
See lines 239-249 in 'osx-app.sh' (assuming you are building from the 0.47 tarball release): here 'xcodebuild' is called to build the launcher as a native osx app. Do you have an up-to-date and complete Xcode installation?
Anyway, it looks as if there is something in osx-app.sh that is not going well - probably relating to the creation of the 45kb executable. More troubleshooting ----
~suv