bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: gettext on Tru64Unix


From: Martin MOKREJŠ
Subject: Re: gettext on Tru64Unix
Date: Wed, 29 Jan 2003 22:41:19 +0100 (CET)

On Wed, 29 Jan 2003, Bruno Haible wrote:

Hi,

  see below:


> Martin Mokrejs wrote:
>
> > > > But I've managed to get it compiled. During "make install",
> > > > the libintl.so go overwritten and because GNU coreutils like
> > > > install(1), cp(1), ln(1) use it, they stopped working.
> > > >
> > > > I had to edit intl/Make tu use installbsd on my platform (Tru64Unix, 
> > > > formerly Digital Unix
> > > > or OSF1) and prepend /usr/bin to my $PATH.
> > >
> > > Can you please explain what happened? I thought the following patch,
> > > already in the CVS, would take care of this problem:
> > >
> > >     2002-09-16  Bruno Haible  <address@hidden>
> > >
> > >         * ltmain.sh (install): Use "ln -s -f" instead of "rm -f && ln -s"
> > >         to make a symlink for a shared library.
> >
> >
> > configure has to figure out, if the ln, rm, install, cp commands use
> > libintl.so and if so, the look for other binaries on the system, which do
> > NOT.
> >
> > In my case, the PATH points first to GNU utilities in
> > /software/@sys/usr/bin/ . But, when the "make install" overwrite
> > libintl.so, it stops working, as the next command is I think install and
> > /software/@sys/usr/bin/install.does not run as the libintl.so is corrupt.
> >
> >
> >
> > > > $ldd /software/@sys/usr/bin/ls
> > > >
> > > >         Main  =>   /software/@sys/usr/bin/ls
> > > >         libintl.so.2  =>   /software/@sys/usr/lib/libintl.so
> > > >         libiconv.so  =>   /software/@sys/usr/lib/libiconv.so
> > > >         librt.so  =>   /usr/shlib/librt.so
> > > >         libc.so  =>   /usr/shlib/libc.so
> > > >         libexc.so  =>   /usr/shlib/libexc.so
> > > > $ ldd /usr/bin/ls
> > > >
> > > >         Main  =>   /usr/bin/ls
> > > >         libc.so  =>   /usr/shlib/libc.so
> > > > $
> > > >
> > > > So, let's use /usr/bin/ls before we make the system unusable.
> > >
> > > I see, but it is not 'ls' which made /software/@sys/usr/lib/libintl.so
> > > go away... ?
> >
> > No, it was:
> >
> > install ... .libs/libintl.so.4.2.0 /software/@sys/usr/lib/libintl.so
> >
> > Since then, nothing worked.
>
> I can neither reproduce nor understand what happened:
>
>   - If your /software/@sys/usr/bin/install is a copy of the OSF/1
>     "install" shell script, it should not be used by GNU gettext -

No:
$ /software/@sys/usr/bin/install --version
install (coreutils) 4.5.3
Written by David MacKenzie.
[...]

This one is preferred by PATH.

This one depends on libintl.so, maybe because I've used those configure
options when compiling it, but anyway:

$ ldd /software/@sys/usr/bin/install

        Main  =>   /software/@sys/usr/bin/install
        libintl.so.2  =>   /software/@sys/usr/lib/libintl.so
        libiconv.so  =>   /software/@sys/usr/lib/libiconv.so
        libc.so  =>   /usr/shlib/libc.so
$


>     there is a catch against this one in the autoconf AC_PROG_INSTALL
>     macro (look for "grep dspmsg"), therefore the one that gets used
>     for me, before installing the GNU coreutils, is "install-sh -c".

Then this did not work and install is preferred before install-sh.

>   - Both "install-sh -c" and the "install" program from GNU coreutils
>     work in an atomic way; at no moment is there no libintl.so on
>     disk.

Moment! I don't have install-sh at all.

>
>   - I tried with GNU coreutils installed, and the gettext install
>     works fine in this case too.

So remove install-sh and see what happens. Be sure the install which
should be used during "make install" is the one which uses libintl.so.
Be sure that that libintl.so is used that install binary.

If you fail to reproduce, I'll redo it once more for you.

BTW: I was talking about /usr/bin/installbsd as the install from OSF1,
which does not use libintl.so (and accepts -c option).

/usr/bin/install is a shellscript. So should autoconf pickup this-one?
This /usr/bin/install is really using /usr/bin/dspmsg, if that helps
to you.

-- 
Martin Mokrejs <address@hidden>, <address@hidden>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585




reply via email to

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