headers
Gary V. Vaughan | 13 Jul 2007 23:27
Picon
Gravatar

Re: m4-1.4.10 compile error: unsigned reference to decimal_point_char

On Jul 13, 2007, at 12:22 PM, Clemens Koller wrote:
> Hi, Gary!

Hi Clemens,

Thanks for the bug report.  I'm forwarding to the bug-m4 mailing list  
for
wider visibility.

This looks like a corner case for one of the files from gnulib that m4
imports during bootstrap:  I'm forwarding to the bug-gnulib mailing list
too, so the author of that code gets the report too.

> m4-1.4.10 doesn't build anymore (1.4.9 built fine):
>
> make[1]: Entering directory `/usr/ports/core/m4/work/src/m4-1.4.10/ 
> src'
> gcc -std=gnu99  -O2 -pipe   -o m4 m4.o builtin.o debug.o eval.o  
> format.o freeze.o input.o macro.o output.o path.o symtab.o  
> stackovf.o ../lib/libm4.a
> ../lib/libm4.a(vasnprintf.o): In function `vasnprintf':
> vasnprintf.c:(.text+0x3690): undefined reference to  
> `decimal_point_char'
> vasnprintf.c:(.text+0x37d8): undefined reference to  
> `decimal_point_char'
> vasnprintf.c:(.text+0x3df0): undefined reference to  
> `decimal_point_char'
> vasnprintf.c:(.text+0x3e48): undefined reference to  
> `decimal_point_char'
> vasnprintf.c:(.text+0x3f0c): undefined reference to
(Continue reading)

Permalink | Reply | 7 comments |
headers
Clemens Koller | 14 Jul 2007 00:58
Picon

Re: m4-1.4.10 compile error: unsigned reference to decimal_point_char

Gary V. Vaughan schrieb:
> Thanks for the bug report.  I'm forwarding to the bug-m4 mailing list for
> wider visibility.

Thanks.

> This looks like a corner case for one of the files from gnulib that m4
> imports during bootstrap:  I'm forwarding to the bug-gnulib mailing list
> too, so the author of that code gets the report too.

Okay.
Please notice, that I am running on an embedded PowerPC (e500 core)
which could also be considered as a corner case platform...

>> m4-1.4.10 doesn't build anymore (1.4.9 built fine):

> Perhaps the copying the vasnprintf.c from an m4-1.4.9 tarball will tide
> you over until the problem is fixed in gnulib?

I never used gnulib in my projects. Can you please give me some more
details how to check which part of gnulib?
I am fine with m4-1.4.9 for my stable repository. Just let me know if
you want to get some patches tested or need more debugging output.

Regards,
--

-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruno Haible | 14 Jul 2007 02:08

Re: m4-1.4.10 compile error: unsigned reference to decimal_point_char

Clemens Koller wrote:
> > m4-1.4.10 doesn't build anymore (1.4.9 built fine):
> >
> > make[1]: Entering directory `/usr/ports/core/m4/work/src/m4-1.4.10/ 
> > src'
> > gcc -std=gnu99  -O2 -pipe   -o m4 m4.o builtin.o debug.o eval.o  
> > format.o freeze.o input.o macro.o output.o path.o symtab.o  
> > stackovf.o ../lib/libm4.a
> > ../lib/libm4.a(vasnprintf.o): In function `vasnprintf':
> > vasnprintf.c:(.text+0x3690): undefined reference to  
> > `decimal_point_char'

Whee. I apologize for this bug. This should fix it:

2007-07-13  Bruno Haible  <bruno <at> clisp.org>

	* lib/vasnprintf.c (decimal_point_char): Define also if
	(NEED_PRINTF_LONG_DOUBLE || NEED_PRINTF_INFINITE_DOUBLE)
	&& !NEED_PRINTF_DIRECTIVE_A.
	Reported by Clemens Koller <clemens.koller <at> anagramm.de> via
	Gary V. Vaughan <gary <at> gnu.org>.

--- lib/vasnprintf.c	11 Jun 2007 01:10:07 -0000	1.58
+++ lib/vasnprintf.c	14 Jul 2007 00:01:26 -0000
 <at>  <at>  -200,7 +200,7  <at>  <at> 
 /* Here we need to call the native sprintf, not rpl_sprintf.  */
 #undef sprintf

-#if NEED_PRINTF_DIRECTIVE_A && !defined IN_LIBINTL
+#if (NEED_PRINTF_DIRECTIVE_A || NEED_PRINTF_LONG_DOUBLE || NEED_PRINTF_INFINITE_DOUBLE) &&
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clemens Koller | 14 Jul 2007 12:22
Picon

Re: m4-1.4.10 compile error: unsigned reference to decimal_point_char

Bruno Haible schrieb:
> Clemens Koller wrote:
>>> m4-1.4.10 doesn't build anymore (1.4.9 built fine):
>>>
>>> make[1]: Entering directory `/usr/ports/core/m4/work/src/m4-1.4.10/ 
>>> src'
>>> gcc -std=gnu99  -O2 -pipe   -o m4 m4.o builtin.o debug.o eval.o  
>>> format.o freeze.o input.o macro.o output.o path.o symtab.o  
>>> stackovf.o ../lib/libm4.a
>>> ../lib/libm4.a(vasnprintf.o): In function `vasnprintf':
>>> vasnprintf.c:(.text+0x3690): undefined reference to  
>>> `decimal_point_char'
> 
> Whee. I apologize for this bug. This should fix it:

Looks good!
Attached is the updated port for CRUX including the patch from Bruno.

Thank you! 

Regards,
--

-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
(Continue reading)

Permalink | Reply | 0 comments |
headers
haibin zhang | 18 Jul 2007 11:24
Picon
Favicon

Re: can't use m4-1.4.8 in Mingw in Windows XP(gcc-3.4.5)


--- Eric Blake <ebb9 <at> byu.net>дµÀ:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> [You can probably drop bug-autoconf and bug-automake
> from your replies]
> 
> According to haibin zhang on 11/22/2006 4:36 AM:
> > HI All:
> > Just now I can't use m4-1.4.8 in Mingw in Windows
> XP( I can compile
> > it,but can't be used)
> 
> It worked fine for me to cross-compile on cygwin
> targetting mingw; in
> fact, that was one of my criteria for a successful
> release.  I haven't
> changed any line-ending behavior in the 1.4.x
> series, so 1.4.8 should
> behave similarly to prior versions of m4 compiled
> for mingw.
> 

I have talked with Mingw team, they told me that
m4-1.4.8 can be used in gcc-2.95.3 and can't be used
in gcc-3.4.5 , beacuse of IO with CRLF line endings.

gcc-2.95.3 default use LF only line endings, but
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Blake | 18 Jul 2007 14:32
Gravatar

Re: can't use m4-1.4.8 in Mingw in Windows XP(gcc-3.4.5)


According to haibin zhang on 7/18/2007 3:24 AM:
> 
> I have talked with Mingw team, they told me that
> m4-1.4.8 can be used in gcc-2.95.3 and can't be used
> in gcc-3.4.5 , beacuse of IO with CRLF line endings.

Based on your quoted email here, the problem is not in m4, but in the
default file mode of binaries created by the version of gcc that you used
to compile m4.  In other words, you have a gcc-2.95.3 compiler that
defaults its resulting binaries into LF mode, and a gcc-3.4.5 compiler
that defaults its resulting binaries into CRLF mode.

> 
> gcc-2.95.3 default use LF only line endings, but
> gcc-3.4.5 default use CRLF line endings.
> 
> I have checked m4-1.4.8 source, it don't support
> Mingw32  directly. it only support cygwin32

Not true - the 1.4.8 (and the current 1.4.10) source compiles on mingw,
with no problems.  What IS true is that I have made no effort to make CRLF
vs. LF line ending distinctions in the upstream m4 source; so far, m4 just
sticks with the defaults of its platform (and thus of the gcc you used to
compile it).

It is also true that 1.4.10 will fail the testsuite on mingw, because I
added a test that relies on strtod("inf") behaving correctly, which it
does not do on mingw (and I have not had time to patch gnulib accordingly
yet).  But that is a platform bug, and not an m4 bug; and since the bug
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Klausner | 20 Jul 2007 00:07
Picon

2 test failures for m4-1.4.10 on NetBSD

Hi!

I just tried the self tests of m4-1.4.10 on NetBSD-4.99.23/amd64.
Two failed:
test-frexpl.c:167: assertion failed
[1]   Abort trap (core dumped) EXEEXT="" EXEEXT...
FAIL: test-frexpl
...
test-printf-frexpl.c:103: assertion failed
[1]   Abort trap (core dumped) EXEEXT="" EXEEXT...
FAIL: test-printf-frexpl

Debugging test-printf-frexpl.c gives:

(gdb) bt
#0  0x00007f7ffdb30576 in kill () from /usr/lib/libc.so.12
#1  0x00007f7ffdbd0af9 in abort () from /usr/lib/libc.so.12
#2  0x0000000000400d92 in main () at test-printf-frexpl.c:103
(gdb) r
Starting program:
/usr/obj/devel/m4/work.x86_64/m4-1.4.10/tests/test-printf-frexpl
test-printf-frexpl.c:103: assertion failed

Program received signal SIGABRT, Aborted.
0x00007f7ffdb30576 in kill () from /usr/lib/libc.so.12

(gdb) l
95            ASSERT (mantissa == my_ldexp (1.0L, i - LDBL_MIN_EXP));
96          }
97
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric Blake | 20 Jul 2007 02:16
Gravatar

Re: 2 test failures for m4-1.4.10 on NetBSD


According to Thomas Klausner on 7/19/2007 4:07 PM:
> Hi!
> 
> I just tried the self tests of m4-1.4.10 on NetBSD-4.99.23/amd64.
> Two failed:
> test-frexpl.c:167: assertion failed
> [1]   Abort trap (core dumped) EXEEXT="" EXEEXT...
> FAIL: test-frexpl
> ...
> test-printf-frexpl.c:103: assertion failed
> [1]   Abort trap (core dumped) EXEEXT="" EXEEXT...
> FAIL: test-printf-frexpl

Thanks for the report.  This means that your system frexpl is broken, and
gnulib's replacement didn't quite work.  Maybe Bruno has more ideas on how
to fix this, since he wrote the gnulib frexpl replacement?

> 
> 
> Debugging test-printf-frexpl.c gives:
> 
> (gdb) bt
> #0  0x00007f7ffdb30576 in kill () from /usr/lib/libc.so.12
> #1  0x00007f7ffdbd0af9 in abort () from /usr/lib/libc.so.12
> #2  0x0000000000400d92 in main () at test-printf-frexpl.c:103
> (gdb) r
> Starting program:
> /usr/obj/devel/m4/work.x86_64/m4-1.4.10/tests/test-printf-frexpl
> test-printf-frexpl.c:103: assertion failed
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Klausner | 20 Jul 2007 13:48
Picon

Re: 2 test failures for m4-1.4.10 on NetBSD

On Thu, Jul 19, 2007 at 06:16:22PM -0600, Eric Blake wrote:
> According to Thomas Klausner on 7/19/2007 4:07 PM:
> > Hi!
> > 
> > I just tried the self tests of m4-1.4.10 on NetBSD-4.99.23/amd64.
> > Two failed:
> > test-frexpl.c:167: assertion failed
> > [1]   Abort trap (core dumped) EXEEXT="" EXEEXT...
> > FAIL: test-frexpl
> > ...
> > test-printf-frexpl.c:103: assertion failed
> > [1]   Abort trap (core dumped) EXEEXT="" EXEEXT...
> > FAIL: test-printf-frexpl
> 
> Thanks for the report.  This means that your system frexpl is broken, and
> gnulib's replacement didn't quite work.  Maybe Bruno has more ideas on how
> to fix this, since he wrote the gnulib frexpl replacement?

Well, the system frexpl is not broken, there just isn't one :)
 Thomas
Permalink | Reply | 0 comments |
headers
Thomas Klausner | 21 Jul 2007 01:05
Picon

m4-1.4.10 breaking autoconf?

Hi!

After the m4 update in pkgsrc there have been reports of breakage in
packages where autoconf is run. In pkgsrc this affects e.g. mng,
firefox, thunderbird and others.

In the case of mng, the output looks like this:
# /bin/rm -f configure.in && /bin/ln -sf makefiles/configure.in .; /bin/rm -f Makefile.am && /bin/ln -sf
makefiles/Makefile.am .; aclocal; /usr/pkg/bin/libtoolize --automake; automake -a --foreign -i; autoconf
configure.in:9: installing `./missing'
configure.in:9: installing `./install-sh'
# ./configure
#

That's the complete(!) configure output.

I'll attach the generated configure script.

Used software:
autoconf-2.61
automake-1.10
libtool-1.5.22
mng-1.0.10 as test case
(all from pkgsrc)

You can get the mng distfile from http://libmng.sf.net/ or
http://prdownloads.sourceforge.net/libmng/libmng-1.0.10.tar.gz?download

Any ideas?
 Thomas
(Continue reading)

Permalink | Reply | 13 comments |

Gmane