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: Thu, 23 Jan 2003 18:30:00 +0100 (CET)

On Thu, 23 Jan 2003, Bruno Haible wrote:

> Martin Mokrejs writes:
> >   I've tried to compile current cvs checkout on Tru64Unix
>
> > I have:
> > and autoconf 2.54 as autoconf
>
> The first line of autogen.sh says that you need autoconf 2.57.

Ah, I should have a look there. ;)
But, I've upgraded to autoconf 2.57 and I get it still:

$ ./autogen.sh
configure.in:76: warning: gl_CHECK_HEADER_stdlib_h is m4_require'd but is not 
m4_defun'd
configure.in:76: warning: gl_CHECK_HEADER_string_h is m4_require'd but is not 
m4_defun'd
$ autoconf --version
autoconf (GNU Autoconf) 2.57
[...]
$ automake --version
automake (GNU automake) 1.7.2
[...]
$ m4 --version
GNU m4 1.4
$

>
> > $ ./configure  --prefix=/software/@sys/usr
> > [...]
> > checking for working alloca.h... yes
> > checking for alloca... yes
> > ./configure: gl_CHECK_HEADER_stdlib_h: command not found
> > ./configure: gl_CHECK_HEADER_stri_: command not found
>
> Strange. I don't observe this, with autoconf 2.57 and m4-1.4o.
>
> > 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.


configur ehas 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 had to do:

/usr/bin/cp intl/.libs/libintl.so.4.2.0 /software/@sys/usr/lib/libintl.so
vim intl/Makefile # replace "install" with "installbsd"
PATH="/usr/bin:$PATH" make install

to recover the system.


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