On 18/03/2011, at 6:52 AM, Gellule Xg wrote:
Is anyone familiar with install_name_tool and the -headerpad_max_install_name or -headerpad linker flags? I might need a little help there.
I saw your latest mail in 'macports-dev' [1] - you seem to have been able to solve it for all dependencies from MacPorts that need to be included in Inkscape.app. Currently, the packaging script relies on a custom $PREFIX for MacPorts (using a path name long enough so that all modules and libs can have their install name rewritten). In bug #532765 [2] I have proposed some changes to the fixlib() function to allow it to work with non-root custom MacPorts installation, and to fix the currently redundant looping and the incorrect ids which are created for most of the dylibs. It works fine for me (I do need those changes because the current fixlib() function doesn't work with my setup - MacPorts tree(s) installed into a separate partition (volume)).
I was hopping to be able to get macports to including something that would let anyone with a standard macports tress build inkscape. In the end, moving /opt/local to /verylooong/local, or adding -headerpad_max_install_name to the default LDFLAGS, or intercepting ld directly, works.
Hi Gellule,
Good to hear about your progress on this.
I'm probably the best person to talk to about the install_name_tool, since I'm the main person working on the OS X packaging scripts. I think the main issue with adding -headerpad_max_install_name to the default LDFLAGS is that it needs to be done when building all the libraries in Macports on which Inkscape depends, not just for the Inkscape code itself. I found that some of these Macports libraries don't have enough space for the path rewriting. One hacky solution might be to put all the dylibs in the Inkscape.app/Contents/MacOS directory along with the inkscape executable resulting in a shorter path of just "@executable_path/libsomething.dylib". I didn't experiment too much to see exactly how long the paths could be, because it takes so long to do the path rewriting -- hence the ridiculously long suggested path currently. Even if you were to move all the libraries there, you'd still need to go about relocating all the GTK and python plugins and correcting their paths for the application.
~suv,
Thanks for your other answers,
I wasn't aware of #532765, but I'll review that for you (may take me a couple of days).
Cheers, Michael
------ Dr. Michael Wybrow, Research Fellow Clayton School of Information Technology Monash University Wellington Rd, Clayton, Vic 3800, Australia Phone: +613 9905 2479 Mobile: +614 2577 2053