Advice on distributing a project

[Langer, Stephen A. (Fed)]

On 6/25/18, 8:42 PM, "Joshua Root" <jmr at macports.org> wrote:

    > 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.

That's what I don't understand.   When not using MacPorts, we use install_name_tool to fix the libraries.  They're built in $HOME/project/build/{lib, include, etc} and moved to $PREFIX /{lib, include, etc}, at which point install_name_tool fixes their ids.  With MacPorts, $PREFIX is ${destroot}${prefix}.  Are the files moved again when the port is installed?  Does the destroot phase need to use an install_name that's different from the actual name, anticipating the later move?
  
    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.)

That's consistent with what we're doing.
    
Thanks for being patient...

 -- Steve