bug-bash
[Top][All Lists]
Advanced

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

Re: undefined reference to `__strtoll'


From: Dave Moore
Subject: Re: undefined reference to `__strtoll'
Date: Fri, 12 Feb 2010 17:45:43 -0500

Bob,
  I didn't read this carefully -- should I try the patch you suggested
before we do anything else?

-dave

On Thu, Feb 11, 2010 at 16:43, Bob Proulx <address@hidden> wrote:

> Greg Wooledge wrote:
> > Dave Moore wrote:
> > > Machine: hppa2.0w
> > > OS: hpux11.00
> > > Compiler: gcc
> > > ...
> > > My version of GCC is
> > > > gcc -v
> > > Using built-in specs.
> > > Target: hppa64-hp-hpux11.00
> > > Configured with: ../src/configure --enable-languages=c,c++
> > > --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
> > > --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --with-gnu-ld
> > > --with-ld=/usr/local/pa20_64/bin/ld --disable-shared --disable-nls
> > > --host=hppa64-hp-hpux11.00
> > > Thread model: single
> > > gcc version 4.0.0
>
> Are you trying to compile a 32-bit executable or a 64-bit executable?
> A 32-bit compile should work okay.  But a 64-bit compile /may/ have
> problems.  You may be better off trying to compile a 32-bit
> executable.
>
> > I don't have an HP-UX 11.00 machine to test on, but:
>
> I don't at this time either.  I used to though.  There is a known
> problem on HP-UX concerning 64-bit compiles.  If the gcc installation
> is trying to use the system header files then this would probably
> trickle through.  The default compilation mode is 32-bit and 32-bit
> builds compile okay.  But a define in <inttypes.h> is upside-down and
> is broken in 64-bit mode.  From coreutils notes I have the following
> patch to the HP-UX system files (use at your own risk) to fix the
> problem.
>
>  --- /usr/include/inttypes.h.orig    Thu May 30 01:00:00 1996
>  +++ /usr/include/inttypes.h         Sun Mar 23 00:20:36 2003
>  @@ -489 +489 @@
>  -#ifndef __STDC_32_MODE__
>  +#ifndef __LP64__
>
> As I recall in 64-bit mode all of the strtoull et al routines are
> broken without this fix.  It might have eventually gotten fixed
> upstream in some later 11.x release by this late date but I don't
> know.  But the problem as reported seems like it may be related.
>
> Bob
>


reply via email to

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