Dave Moore wrote:
> I didn't read this carefully -- should I try the patch you suggested
> before we do anything else?
Yes. (Dave and I had some private email exchange where we discussed
the contents of <inttypes.h> on his system. I see that he is
suffering from the bug that I described.)
The problem is that strtoimax and strtoumax are defined as macros in
the <inttypes.h> file and they are not working in 64-bit mode.
Here is a summary.
grep strtoumax /usr/include/inttypes.h
#ifndef __STDC_32_MODE__
#define strtoumax(__a, __b, __c) __strtoll(__a, __b, __c)
#else
#define strtoumax(__a, __b, __c) (intmax_t)strtol(__a, __b, __c)
#endif
One is for 32-bit and one is for 64-bit. For 32-bit compiles you want
the __strtoll version and for 64-bit compiles you want the strtol
version. Unfortunately they are erroneously reversed in that header
and that breaks 64-bit compiles because in 64-bit mode you get the
"__strtoll" symbol which is available only in the 32-bit libraries.
The result is seen as an unresolved reference in the linker output:
bash-4.1/braces.c:395: undefined reference to `__strtoll'
With line bash-4.1/braces.c:395 being:
tr = strtoimax (rhs, &ep, 10);
I recommend fixing this by editing the system file and correcting the
define. That would help much software going forward. Since you are
using gcc it will have a private version of this file. At the least
you should be able to modify it and get relief when using gcc.
In your file
/usr/local/pa20_64/lib/gcc/hppa64-hp-hpux11.00/4.0.0/include/inttypes.h
change line 508 from __STDC_32_MODE__ to __LP64__ and then recompile
everything and I think you will see some relief from the
"ld: Unsatisfied symbol "__strtoull" in file ..." (HP-UX cc) and
"undefined reference to `__strtoll'" (gcc) problem.
To fix this for the native HP-UX C compiler in 64-bit mode make the
same change to the /usr/include/inttypes.h file.
I don't know about the ld core dump though. That shouldn't happen
regardless.
Hope this helps!
Bob
