tech-pkg archive

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


On Thu, Aug 08, 2019 at 01:56:59PM +0200, Martin Husemann wrote:
> On Thu, Aug 08, 2019 at 12:49:54PM +0100, Patrick Welche wrote:
> > What does pkgsrc do to $ORIGIN and why?
> It (the wrappers) removes all traces of it from the linker command
> line, so no binaries created by pkgsrc will have a $ORIGIN.
> The reasoning is that the meaning of shared libs is not "position indepent"
> with $ORIGIN (exactly as that is what it is about), so it is unclear if
> the same libs will be used in the build directory as in the final installed
> version. Proponents of this behaviour will find more harsh words for the
> misbehaviour with $ORIGIN present ;-)

On install, meson then zaps RPATH completely (which is the other extreme), so
no $ORIGIN is left lying around.

I was going back to the libtool way, which was to replace the build tool
with a script which set LD_LIBRARY_PATH to $builddir/.libs, so the build tool
could run.

It seems the meson equivalent is to set $ORIGIN. e.g.,

  RPATH     /usr/pkg/lib:$ORIGIN/../girepository:$ORIGIN/../girepository/cmph

Just to make debugging more entertaining, if you had succeeded in
building gobject-introspection, a libgirepository will be happily
living in /usr/pkg/lib and get found. I would claim that RPATH is correct
for the uninstalled build tool without the /usr/pkg/lib.

Setting LD_LIBRARY_PATH in every meson-using package with a build
tool is doable (why dump that on me?), but have you seen what is
necessary on MacOS to do the same?
(c.f. Clement Bouvier and Brook Milligan posts.)



Home | Main Index | Thread Index | Old Index