At Wed, 11 Mar 2020 20:34:11 -0400, Jeffrey Walton <noloader%gmail.com@localhost> wrote: Subject: Re: Shared object "libintl.so.9" not found (but its there) > > I don't follow. Please forgive my ignorance. > > I'm building using my build scripts from > https://github.com/noloader/Build-Scripts . They feature test, set > package options, configure, make and make install. Everything someone > would do manually. Nothing fancy. > > This does not make sense, either: > > $ ldd /usr/pkg/bin/git > /usr/pkg/bin/git: > -lpcre2-8.0 => /usr/pkg/lib/libpcre2-8.so.0 > -lpthread.1 => /usr/lib/libpthread.so.1 > -lc.12 => /usr/lib/libc.so.12 > -lz.1 => /usr/lib/libz.so.1 > -lintl.1 => /usr/lib/libintl.so.1 "git" is not "git-submodule". They are likely separate binaries, where "git submodule" invokes "git-submodule". > I can't seem to get more information though: > > $ LD_DEBUG=files git submodule --init > Shared object "libintl.so.9" not found > Shared object "libintl.so.9" not found > Shared object "libintl.so.9" not found > Shared object "libintl.so.9" not found I'm going to guess that "git-submodule" was compiled to use the "libintl.so.9" version that you have/had installed in /usr/local/lib, but the build didn't bake in the runtime path for that library, so the runtime linker can't find it (it doesn't look in /usr/local/lib by default). You could probably work around this by configuring /etc/ld.so.conf, or even by setting LD_RUN_PATH in the environment, but the best fix is to make sure the linker gets the required "-rpath=" options when building the "git-submodule" binary. Or just static link everything. That's what I do. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgplyTFWsKjD3.pgp
Description: OpenPGP Digital Signature