[Top][All Lists]

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

Re: m4-1.4q on Tru64Unix

From: Martin MOKREJŠ
Subject: Re: m4-1.4q on Tru64Unix
Date: Wed, 15 Oct 2003 00:28:58 +0200 (CEST)

On Tue, 14 Oct 2003, Gary V. Vaughan wrote:

> Martin MOKREJŠ wrote:
> > On Fri, 10 Oct 2003, Gary V. Vaughan wrote:
> >
> >
> >>That will stop the SEGV, but I fear there is something deeper going wrong, 
> >>as
> >>one of the handles must have a null name.
> >>
> >>If you can give me SSH access to your machine I'll be able to help you 
> >>debug it...
> >
> >
> > How about http://testdrive.hp.com/systems/alpha.shtml
> Well, I signed up for an account, transferred the m4 sources to one of the
> alpha ev7's, and the build chokes on perl.c with the `cannot specify -o with
> -c or -S and multiple compilations' error you reported last week :-(  I think
> this is some problem with gcc vs DEC ld...
> Next, I tried `configure CC=cc', and the build completed, and the testsuite
> showed the same test failures you reported, but in the testsuite.log I get
> `libiconv has no entry points'.  No SEGV, no core dump. Bah! :-(
> Finally, I tried `configure CC=cc --disable-nls', but despite the lack of
> internationalisation, I still get iconv errors in the logs. :'(
> What configure and compiler options did you use to generate the SEGV?  I can't
> find a way to reproduce it...

CFLAGS/CXXFLAGS="-O0 -arch ev56 -g3"

$ cc -V
Compaq C V6.5-207 (dtk) on Compaq Tru64 UNIX V5.1A (Rev. 1885)
Compiler Driver V6.5-207 (dtk) (dtk) cc Driver

OK, I edited the config.status to get the debug options, so actually I
configured as:

configured by ./configure, generated by GNU Autoconf 2.57f,
  with options \"'--prefix=/software/@sys/usr' 'CC=cc' 'CFLAGS=-O2 -arch
ev56' 'CPPFLAGS=-I/software/@sys/usr/include -I/usr/local2/include
-I/usr/local/include -I/usr/local2/openssl/include' 'CXXFLAGS=-O2 -arch
ev56' 'CXX=cxx'\"

rerunning configure says:

checking whether NLS is requested... yes
checking for msgfmt... /usr/local2/bin/msgfmt
checking for gmsgfmt... /usr/local2/bin/msgfmt
checking for xgettext... /usr/local2/bin/xgettext
checking for msgmerge... /usr/local2/bin/msgmerge
checking for non-GNU ld... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for shared library run path origin... done
checking whether NLS is requested... yes
checking for GNU gettext in libc... no
checking for iconv... yes
checking how to link with libiconv... /software/@sys/usr/lib/libiconv.so -rpath 
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... /software/@sys/usr/lib/libintl.so 
-L/software/@sys/usr/lib -L/usr/local/lib -L/usr/local/openssl/lib 
/software/@sys/usr/lib/libiconv.so /usr/lib/libc.a -rpath /software/@sys/usr/lib
checking for gettext.h... no
checking for a BSD-compatible install... /software/@sys/usr/bin/install -c
checking whether make sets $(MAKE)... (cached) yes
checking for perl... /software/@sys/usr/bin/perl
checking for gawk... (cached) gawk

Disabling nls doesn't help the test to pass, but I don't get coredump
anymore. ;) So a gettext bug? Attached the tests output.

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

Attachment: tests.tgz
Description: Binary data

reply via email to

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