pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Set install_name to fix devel/mustach on macOS



Hi Greg,

> Op 27 dec. 2019, om 15:42 heeft Greg Troxel <gdt%lexort.com@localhost> het volgende geschreven:
> 
> Sijmen Mulder <ik%sjmulder.nl@localhost> writes:
> 
>> devel/mustach builds are failing on macOS because no install_name is
>> set. Attached patch should fix it (and does so on my machine) but
>> I'd appreciate someone with macOS experience taking a look.
>> 
>> Build failure:
>> https://us-east.manta.joyent.com/pkgsrc/public/reports/Darwin/10.14/trunk/x86_64/20191220.0920/mustach-0.99/install.log
>> 
>> Upstream PR:
>> https://gitlab.com/jobol/mustach/merge_requests/16
>> 
>> ok?
> 
> I am having trouble following.  The diff upstream and this diff don't
> look the same.

The Makefile changes should be identical; in fact I generated the
patch from the git commits. Note that the pull requests is a two parter
since I made a mistake in the first commit and corrected it with the
second.

> Also, it seems like upstream does not require gmake, and the patch
> introduces a gmake dependency.  It would seem our usual approach (beyond
> an upstream-ok patch) would be  to SUBST something like
> @installnameflags@ to either what macos needs or empty, depending on OS
> in our Makefile.

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.

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

Sijmen


Home | Main Index | Thread Index | Old Index