On 6/25/18, 8:42 PM, "Joshua Root" <[email protected]> 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
