Advice on distributing a project

[Joshua Root]

> 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