Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%joyent.com@localhost> writes:

> * On 2020-02-16 at 19:39 GMT, Brook Milligan wrote:
>
>> > On Feb 16, 2020, at 12:06 PM, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
>> > 
>> > * On 2020-02-16 at 18:40 GMT, Brook Milligan wrote:
>> > 
>> >> Just for reference, are your MacOS builds on systems with SIP
>> >> enabled?  Can you export LD_LIBRARY_PATH into your shell
>> >> environment?  (I cannot with SIP enabled.)
>> >> 
>> >> I think you are correct that pkgsrc uses LD_LIBRARY_PATH when
>> >> needed.  However, SIP removes that from the environment, so it does
>> >> not help in situations like this.  I believe that is why I can build
>> >> these packages with SIP disabled, but not when enabled.  
>> > 
>> > None of my build machines enable SIP, it breaks any possibility to
>> > create sandboxes which are required for builds.  My desktop is
>> > SIP-enabled, but that only installs the binary packages that are
>> > produced on the non-SIP build machines, I don't build on it.
>> > 
>> > I guess that's the problem then.  I wasn't aware it also disabled use
>> > of {DY,}LD_LIBRARY_PATH.
>>
>> Yes, it does.  That explains the difference between our results.
>> 
>> So, should the guidance be, “Disable SIP on MacOS”?  If so, that
>> needs to be documented somewhere.
>
> That seems entirely reasonable to me.  SIP breaks lots of things that
> advanced users on macOS rely on, like DTrace, and I would classify
> manually building pkgsrc as belonging to that category.

I see your point, but I think it's very much not ok for pkgsrc to tell
people to turn off SIP.  To me that sounds very much like "pkgsrc can't
cope, so you should use macports or brew instead".  Building software
that does not intend to write to protected areas (after all we have
/opt/pkg now as the norm) seems like something that should work.
(DTrace is another story, and I won't disagree there.)

It's not that anything ought to be happening that is prohibited by SIP;
it's that the build process is doing something that is not allowed, but
seems entirely avoidable.  The upstream build apparently works with SIP
enabled, and we're basically in a bad state with the combination of:

  SIP doesn't allow LD_LIBRARY_PATH

  pkgsrc norms remove some things upstream puts in from the build

  upstream expects the thing that it adds to be respected (both $ORIGIN
  and LD_LIBRARY_PATH, although I'm not sure that leaving $ORIGIN in
  would make the build owrk; we are pretty sure about LD_LIBRARY_PATH)

Arguably, macOS is wrong to ignore LD_LIBRARY_PATH for a library that
would not be found in the subspace protected by SIP; it certainly makes
sense to not let people replace libc.

But this approach doesn't let users build things without going through a
messy reboot/disable/build-pkgsrc/reenable set of steps.

It would be nice if we had binary packages that worked on 10.13.  I
don't mean to criticize you for moving your build to 10.15.  But it
would take someone to volunteeer to set up a build farm or maybe one
really expensive box.  I say 10.13 because there is a lot of perfectly
OK hardware that is stuck on 10.13.  (There is some stuck on 10.11, but
it's even older.)

> It's worth mentioning that this is only for building.  Installing
> pkgsrc binary packages has no such requirement.

Agreed.