> Op 27 dec. 2019, om 18:53 heeft Greg Troxel <gdt%lexort.com@localhost> het volgende geschreven:
>
> Sijmen Mulder <ik%sjmulder.nl@localhost> writes:
>
>> [...]
>>
>> The gmake dependency is unfortunate but for the PR I saw no way (except
>> switching build systems entirely) to have a Mac-only flag other than an
>> if statement, and those aren't portable between make systems. GNU make
>> then seemed like the safest choice.
>
> If upstream merges your PR and documents gmake, that's how it is and
> pkgsrc should of course adapt on next update. It just seems a bit much
> as a pkgsrc patch, especially as the freeze is nearing hte end.
>
>> I’m not sure what you mean with the '@installnameflags@' thing (where
>> would that be defined?) but a non-patch alternative would be to add a
>
> I meant that pkgsrc has a way to substitute things in files, and the
> usual plan is to use @foo@ in the file and then change it to the right
> thing with SUBST_SED.
>
> See net/ettercap-NG for an example, although it is not conditionalize by
> OS. There are a a lot of SUBST_
Ack to both points, thanks for explaining.
>> post-install target on Darwin only that runs
>>
>> install_name_tool -d ${PREFIX}/lib/libmustach.so ${PREFIX}/lib/libmustach.so
>>
>> A quick grep for install_name_tool shows that many packages do this.
>
> In freeze, I would really prefer that, especially given precedent.
New patch attached.
> Longer term, it would be nice to have some higher-level declarative
> workaround. I suppose this is either a bug in upstreams or a bug in
> macos (is install_name covered by any standards?) depending on how you
> look at it :-)
It's used to add the installed library's location to the list of library
search paths of macOS binaries (at link time):
An install name is just a pathname embedded within a dynamic library
which tells the linker where that library can be found at runtime.
For example, libfoo.dylib might have an install name of
/usr/lib/libfoo.dylib. This install name gets copied into the
application at link time. When the dynamic linker goes looking for
libfoo.dylib at runtime, it will fetch the install name out of the
application and know to look for the library in /usr/lib.
https://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html
So it's a different mechanism, one any install target for projects
wanting to support macOS should account for (so yes, upstream).
Sijmen
Attachment:
mustach-v2.patch
Description: Binary data