Re: [PATCH] devel/talloc: Fix library install names on Darwin

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2016-02-18 at 18:21 GMT, Greg Troxel wrote:

> "J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> 
> > On 2/18/16 10:39 AM, Greg Troxel wrote:
> >> I am talking about easing the burden of adding workarounds.  OS X is
> >> odd, and that means that these issue will continue to be common.  Your
> >> changes were slightly hard to follow, and on reflection seem like they
> >> could be factored out into a list of libraries to patch and a list of
> >> dependencies to adjust, so that there would be two variables set, and
> >> no need for the open-coded version.
> >
> > Ah, I see.  If there was some way to factor things out, then I agree
> > that might be a nice help.  The install_name_tool "-id" option would be
> > pretty easy.  The "-change" option would be a little harder because it
> > needs the exact old-value string to be replaced, and that will likely
> > vary.  But I suppose the infrastructure could figure out the exact
> > old-value string using pattern matching on the output of "otool -L
> > library_file".
> 
> I meant something less magic.   More like
> 
> DARWIN_LIBS_FIXUP=
>   [list of libs, relative to DESTDIR, that need to be patched]
> 
> DARWIN_LIBS_FIXUP_REFS=
>   [list of libs, relative to destdir, that need to be changed from the
>   destdir path to the eventual path, in all of the above]

Ultimately this will be nice, but I think it's too soon to start
adding a generic way of handling this.  One of the problems I've
recently hit is that the fixes may need to occur at different times in
the build, and there may be additional issues which a generic solution
may not yet be designed to handle.  I just don't think we have enough
experience fixing these problems yet.

See my recent fix to databases/tdb as an example.  Firstly we need to
fix at post-build time, as during install the binaries are relinked
against the library and will pull in whatever the name is currently
set to.  We then need to fixup the final library after it has been
installed.  It may of course be possible to patch the build process to
do this properly, but it's opaque waf crap that I wasn't prepared to
spend hours churning through.

I recently (yesterday) found a new class of issues in our Darwin
packages, where the REQUIRES path may be relative (e.g.
"lib/libfoo.dylib"), which passes the shlibs check but fails at
runtime.  Fixing those will give us more data on the different classes
of fixes required.

My current thinking is that perhaps it might be good to integrate this
into the subst framework, as that supports different build phases, and
has SUBST_FILTER_CMD for ad-hoc commands against specified files, but
then it may turn out even more verbose than the current open coded
versions.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com