bug-gnulib
[Top][All Lists]
Advanced

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

Re: (sharutils) make distclean removes doc/uudecode.1


From: Bob Proulx
Subject: Re: (sharutils) make distclean removes doc/uudecode.1
Date: Sat, 6 Apr 2013 18:28:44 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

Bruce Korb wrote:
> The last dinkleberry has to do with libintl.
> On OS/X:
> > $ ldd ../src/shar
> >         libintl.so.8 => /usr/local/lib/libintl.so.8 (0x0000020000036000)
> >         libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000054000)
> >         libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x00000200001f4000)
> >         /lib/ld-linux.so.2 (0x0000020000000000)

You have LD_LIBRARY_PATH set including /usr/local/lib?

> > $ unset LD_LIBRARY_PATH
> > $ ldd ../src/shar
> >         libintl.so.8 => not found
> >         libc.so.6.1 => /lib/libc.so.6.1 (0x0000020000036000)
> >         /lib/ld-linux.so.2 (0x0000020000000000)

I don't know about OS/X so this response may not be useful.  (Is that
IBM OS/2?  Mac OS X?)  But on a GNU/Linux system such as Debian there
is a /etc/ld.so.conf (which includes /etc/ld.so.conf.d/*) that
includes /usr/local/lib as configuration for the runtime ld.so linker.
In this configuration LD_LIBRARY_PATH is not needed for the ld.so to
locate libs in /usr/local/lib because the ld.so.conf will include it.
Then ldconfig is used to create the ld.so.cache which caches the
locations of candidate libraries previously found in the search path.

If your OS is similar then I suspect that it's ld.so.conf (or
equivalent) file is missing the /usr/local/lib configuration.

> It _looks_ like it finds libintl in /usr/local/lib and then
> links the executables without marking it with:
>    -Wl,-rpath -Wl,/usr/local/lib
> Shouldn't that incantation be pretty automatic?

The issue of rpath has been a hot-button of contention over the years.
It is similar to the conflict between searching for executables using
PATH and hard coding the full path to executables.

Rpath should not be needed if the ld.so is configured properly.
Therefore I would look there for the problem and solution first.
Assuming your OS/X uses an ld.so dynamic linker.  If it doesn't use a
dynamic linker then it may very well be hard coding the paths to
everything.  In which case setting LD_LIBRARY_PATH might be the lessor
of the evils.  In which case ignore this message because it doesn't
apply.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]