Re: [gtk-osx-devel] install_name_tool and El Capitan

[John Ralls <jralls ceridwen us>]

> On Jan 23, 2016, at 11:24 AM, philip chimento gmail com wrote:
>
> Hi list,
>
> It seems that on El Capitan we have to postprocess some libraries with install_name_tool before they can be 
> linked. I ran into this problem with nspr and js24, and from John's comment in 
> jhbuildrc-gtk-osx-custom-example, which pointed me in the right direction, I see he has had the same 
> problem with boost.
>
> For anyone else with the same problem, I had to change libmozjs-24.dylib with install_name_tool -id 
> /full/path/to/libmozjs-24.dylib libmozjs-24.dylib, then also change some of its dependencies with 
> install_name_tool -change @executable_path/libdependency.dylib /full/path/to/libdependency.dylib 
> libmozjs-24.dylib, then repeat the install_name_tool -change for any of those dependencies that depended on 
> each other (though I didn't have to repeat install_name_tool -id for the dependencies).
>
> I'm looking for ideas on how to get these modules building again without the intervention of 
> install_name_tool. But I admit I don't understand what the issue is here and why this is necessary, or how 
> to get the libraries to just build with the correct paths from the get-go. (I assume it would be some -Wl 
> linker flag that we would have to patch into any module that is affected? Or maybe the answer is to get 
> jhbuild to do this path rewriting automatically during a module's install phase?)

I think the Right Way is to understand and tweak the build system so that it sets the id to $PREFIX. If 
you're getting @executable_path paths then the build system has figured out that you're building on a mac and 
is adjusting the paths for an app-bundle installation. You want to defeat that and get it to use plain paths.

BTW, jhbuild can't at the moment even build boost because it lacks a bjam module, which makes it easy to fix 
the id. Boost has no dependencies so that wasn't a problem for me.

Regards,
John Ralls