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?) Regards, Philip
_______________________________________________ Gtk-osx-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
