tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango
* On 2020-02-16 at 17:38 GMT, Greg Troxel wrote:
> Jonathan Perkin <jperkin%joyent.com@localhost> writes:
>
> > * On 2020-02-16 at 14:47 GMT, Greg Troxel wrote:
> >
> >> I got an offlist comment that this is a wrappers (pkgsrc) bug, with
> >> $ORIGIN being removed when it shouldn't. So probably if you build w/o
> >> pkgsrc it would work.
> >>
> >> You could also try traditional wrappers vs cwrappers.
> >
> > Can we please stop spreading FUD. Removing $ORIGIN is a pkgsrc policy
> > and intrinsically tied into the way that we build software and how we
> > believe software should be built.
>
> And it is, as far as I can tell completely undocumented, so it is not
> surpising that the people not involved in writing this bit of code do
> not understand it:
>
> ORIGIN does not appear in doc/pkgsrc.txt
>
> ORIGIN does not appear in pkgtools/cwrappers
>
> ORIGIN does not appear under mk
>
> So perhaps it is removed implicitly by some other rule and if I found
> that there would be comments that explained, but they seem not to
> mention ORIGIN, and it seems a common enough issue that it seems it
> should be mentioned.
It is implicit in the design and implementation of buildlink. We
don't mention /usr/gnu/lib or /opt/csw/lib in the documentation
either, but they are also removed during builds. $ORIGIN is no
different, it's just another path that is not permitted along with any
other that is not explicitly permitted.
I thought buildlink had been well documented over the years, and was
under the impression it was well understood by developers - at least
the reasoning behind the whole philosophy, but maybe it needs to be
improved from a new user perspective?
> > It is not a bug in the wrappers, whether the C versions or otherwise.
>
> Can you explain, then, how pkgsrc should be building things that use
> meson, or how we should be patching the meson-using build systems, so
> that things actually build?
>
> My limited understanding is that pkgsrc is basically saying meson is
> wrong, and leaving things broken.
>
> As an example, building gobject-introspection via pkgsrc-2019Q4 on macOS
> 10.13 leads to
>
> dyld: Library not loaded: @rpath/libgirepository-1.0.1.dylib
>
> and failure. This seems to be the same issue Brook is talking about.
>
> Are you able to build gobject-introspection on mac?
I don't know why it's failing, perhaps it's been fixed since then? I
post regular macOS bulk builds and as you can see from them I don't
see the same problem.
The way it should work is the same as we modify all other builds in
pkgsrc that don't use libtool and require libraries from within the
work area during build - we LD_LIBRARY_PATH them only for the parts of
the build that require them.
It feels like we had this exact conversation not that long ago - I'd
suggest checking the tech-pkg archives for the previous meson thread.
--
Jonathan Perkin - Joyent, Inc. - www.joyent.com
- References:
- MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango
- Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango
- Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango
- Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango
- Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango
Home |
Main Index |
Thread Index |
Old Index