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

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

Re: Problem when building on HP-UX 11i(11.11)


From: Bob Proulx
Subject: Re: Problem when building on HP-UX 11i(11.11)
Date: Tue, 11 Mar 2003 12:58:53 -0700
User-agent: Mutt/1.3.28i

Leon Strydom wrote:
>  
> I am tring to build GNU tar 1.13.25 on HP-UX 11.11.
> I get the following error:
> "ld: Unsatisfied symbol "__strtoull" in file
> ../lib/libtar.a[xstrtoumax.o]"

Thanks for your bug report.  There does indeed seem to be some trouble
there.

Could you say exactly what compile options you were using?  Were you
trying to compile in 64-bit mode?  Or 32-bit mode?  I believe you must
be trying to compile in 64-bit mode.  I can recreate your problem
using the +DD64 option.

The problem is that strtoimax is defined as a macro in <inttypes.h>.

  grep strtoimax /usr/include/inttypes.h
  #ifndef __STDC_32_MODE__
  #define strtoimax(__a, __b, __c) __strtoll(__a, __b, __c)
  #else
  #define strtoimax(__a, __b, __c) (intmax_t)strtol(__a, __b, __c)
  #endif

One is for 32-bit and one is for 64-bit.  Unfortunately they are
erroneously reversed in that header and that breaks 64-bit compiles
there.  It should be possible for the configure script to detect that
case and to work around it.  [Note to the configure maintainers, would
it be possible to add a test for a broken strto*l macro?  I seem to
recall Jim having worked on something similar previously.]

As a workaround for the configure script not knowing about this system
problem you could correct the system header.  The following patch will
correct the bug in /usr/include/inttypes.h and allow strto[iu]max() to
work not just for tar but for other programs as well.

--- inttypes.h.orig     Tue Nov 14 01:00:00 2000
+++ inttypes.h  Tue Mar 11 03:10:48 2003
@@ -493,7 +493,8 @@
 ** they may have.
 */
 
-#ifndef __STDC_32_MODE__
+#ifndef __LP64__
 
 #ifdef __cplusplus
 extern "C" { 

With this correction to the <inttypes.h> file everything compiled in
64-bit mode and the 'make check' passed.  This would be one way to
solve your problem.

But trying to compile in 32-bit mode I ran across another problem.  It
is related.

cpp: "xstrtol.c", line 90: warning 2005: strtoimax: Too few parameters (1) to 
macro.
cc: "xstrtol.c", line 90: error 1000: Unexpected symbol: ",".
cc: "xstrtol.c", line 90: error 1506: Parameters allowed in function definition 
only.

Here is the relevant code.

#if !HAVE_DECL_STRTOIMAX
intmax_t strtoimax ();
#endif

Here are some related configure output lines.

checking whether strtoul is declared... yes
checking whether strtoull is declared... no
checking whether strtoul is declared... yes
checking whether strtoull is declared... no
checking whether strtoumax is declared... yes
checking whether <inttypes.h> defines strtoumax as a macro... yes

I found a log entry about HAVE_DECL_STRTOIMAX.  But I can't find where
it is getting set or not set?  Perhaps the jm_AC_PREREQ_XSTRTOUMAX
configure macro can be adapted for that purpose.  And perhaps more
likely I am missing obvious things.

If I remove the prototype of strtoimax() from xstrtol.c then I can get
past this error.  Here is my minimul change and the code compiled.

#if !HAVE_DECL_STRTOIMAX
/* intmax_t strtoimax (); */
#endif

At this point using the native compiler in 32-bit mode everything
compiled fine and 'make check' passed all tests.  There were some
warning messages.  But none that would prevent correct operation.

I don't know what the best correction would be.  I will just point to
the problem and let the others on the list determine the best
solution.

Hope that helps.

Bob




reply via email to

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