Re: undefined reference to `__strtoll'

[Bob Proulx]

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