(sharutils) make distclean removes doc/uudecode.1

[Zube]

In sharutils 4.13.4 (and at least 4.13.3, possibly older versions too),
"make distclean" removes doc/uudecode.1. Trying to rebuild afterwards
results in:

gmake[2]: Entering directory `/src/sharutils-4.13.4/doc'
gmake[2]: *** No rule to make target `uudecode.1', needed by `all-am'. Stop.

> diff -r sharutils-4.13.4 cleanedsource
Only in sharutils-4.13.4/doc: uudecode.1

Cheers,
Zube

[Bruce Korb]

Nelson Beebe found a "shar-1" test failure on a few of his many platforms.
I cannot reproduce it -- even on the platform that he had the failure on.
Meanwhile, if you like:
http://autogen.sourceforge.net/data/sharutils-4.13.5pre1.tar.xz
That definitely fixes the issue you see.

[Bruce Korb]

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)
> $ 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)

There must be some magic that I am missing. I have a bunch of
"intl" files, including m4 macros, but something is wrong:

> $ find . -type f -name '*intl*' -o -name '*gettext*'
> ./intl/gettext.c
> ./intl/intl-compat.c
> ./intl/dcngettext.c
> ./intl/libintl.rc
> ./intl/ngettext.c
> ./intl/dcgettext.c
> ./intl/dcigettext.c
> ./intl/intl-exports.c
> ./intl/gettextP.h
> ./intl/dgettext.c
> ./intl/libgnuintl.h.in
> ./intl/dngettext.c
> ./libopts/gettext.h
> ./lib/gettext.h
> ./m4/gettext.m4
> ./m4/intldir.m4
> ./m4/intlmacosx.m4
> ./m4/intl.m4

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?

[Bob Proulx]

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

[Bruce Korb]

Hi Bob,

Thank you for your pointers!

Bob wrote:> Bruce Korb wrote:
>> The last dinkleberry has to do with libintl.
>> On OS/X:

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

It was forced (and done by hand) because without it:

>> > $ unset LD_LIBRARY_PATH
>> > $ ldd ../src/shar
>> > libintl.so.8 => not found

> I don't know about OS/X so this response may not be useful.

I confess, I don't develop much on OS/X. I was granted access
to a mess of build platforms at U of Utah and this is just one.
I ran a script that did the same thing on all platforms:

mkdir /local/shar-$$ && \
cd /local/shar-$$ && \
configure ~/shar-src && \
make && \
make check && \
make install DESTDIR=$HOME/_$(uname -n) && \
rm -rf /local/shar-$$

To my naive way of thinking, that should just work.
The configure step clearly figures out that libintl
lives in /usr/local, but the build instructions don't
do the right thing to yield a working executable:

>> 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.

OK, so when someone complains I should say, "works as designed"?
Just how hard is it to test to see if /path/to/libintl.so is in
the default link/loader path for a platform? Then, if not,
either link against libintl.a or do the proper incantation to
make the link/loader look there at run time. How hard can that
be? What I _don't_ want is for "configure" to say "all is well"
and then have the program fall over because it really wasn't.

> Therefore I would look there for the problem and solution first.

If it were my platform, I'd just fix it. I am not an admin, but
a guest being given the opportunity to test a release before
releasing it.

I guess I like simple solutions. "Do thus and so and all is well."

*sigh*. Thanks - Bruce