> I still have at least one problem. We had to extend distutils so that it > builds a few .dylib shared libraries that are linked to by the more > standardly built python extension modules, which are all .so bundles. All of > them are being installed in the correct location, but the .dylibs retain the > install name and id that they were given when they were built. The destroot > phase has somehow fixed those for the .so files. How can I tell it to do > the same for the .dylibs? "otool -L" shows that the .dylibs have the wrong > ids and are linking to the other .dylibs in the wrong locations, and that the > .so's have the right ids but are also linking to the wrong .dylibs. (I don't > remember why the shared libraries are .dylibs and not .sos. Perhaps it's no > longer necessary and I should change them all to .so?)
I'd suspect your extended version of distutils is not passing all the linker arguments that it needs to. (Can you share it?) When you build a dylib, you need to use an appropriate -install_name argument. You could fix it afterwards using install_name_tool, but it's better to get it right to begin with. The filenames technically don't matter at all as long as they're used consistently when things link to other things, but the convention is that .dylib is for libraries (i.e. things that publish some interface for other things to use). The use of .so is a less strong convention, but it's often used for plugin objects (i.e. things that are loaded by an executable at runtime, and use symbols provided by the executable.) - Josh
