undefined reference to `__strtoll'
Configuration Information [Automatically generated, do not change]: Machine: hppa2.0w OS: hpux11.00 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='hppa2.0w' -DCONF_OSTYPE=' hpux11.00' -DCONF_MACHTYPE='hppa2.0w-hp-hpux11.00' -DCONF_VENDOR='hp' -DLOCALEDI R='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DHPUX -I . -I. -I./include -I./lib -g -O2 uname output: HP-UX halflife B.11.00 U 9000/785 2012264887 unlimited-user licens e Machine Type: hppa2.0w-hp-hpux11.00 Bash Version: 4.1 Patch Level: 0 Release Status: release Description: I'm having trouble compiling bash on HP-UX 4.1. I can't figure out how to work around it. Basically, the version of HP-UX I'm running on doesn't have strtoll. So when I'm building, I see these errors: gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh-g -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory -lcurses -ltilde -lmalloc -lintl -ldl collect2: ld terminated with signal 11 [Segmentation fault], core dumped general.o(.text+0x334): In function `legal_number': /home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to `__strtoll' braces.o(.text+0xae4): In function `brace_expand': /home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to `__strtoll' ./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax': ./printf.def:998: undefined reference to `__strtoll' make: *** [bash] Error 1 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 Any help appreciated, -dave
Re: undefined reference to `__strtoll'
Hi, So how do I compile the 32-bit version of bash? Should I uninstall the GCC compiler I have and goto 3.4.6 like an earlier poster? -dave On Thu, Feb 11, 2010 at 16:43, Bob Proulx 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 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.origThu 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 >
Re: undefined reference to `__strtoll'
How do I configure the linker to use the system linker instead of gnu LD?
I really appreciate the replies!
-dave
On Thu, Feb 11, 2010 at 15:49, Greg Wooledge wrote:
> On Thu, Feb 11, 2010 at 12:58:46PM -0500, Dave Moore wrote:
> > Machine: hppa2.0w
> > OS: hpux11.00
> > Compiler: gcc
>
> > Bash Version: 4.1
> > Patch Level: 0
>
> I don't have an HP-UX 11.00 machine to test on, but:
>
> > I'm having trouble compiling bash on HP-UX 4.1. I can't figure out how
> to
> > work around it. Basically, the version of HP-UX I'm running on doesn't
> have
> > strtoll.
>
> It's not supposed to, as far as I'm aware. __strtoll is an internal
> libc thing.
>
> bash-3.2# uname -sr
> HP-UX B.11.11
> bash-3.2# cd /usr/include
> bash-3.2# find . -name '*.h' -exec grep strtoll /dev/null {} +
> ./inttypes.h:extern intmax_t __strtoll (const char *, char**, int);
> ./inttypes.h:extern intmax_t __strtoll ();
> ./inttypes.h:#define strtoimax(__a, __b, __c) __strtoll(__a, __b, __c)
>
> There's no man page for "strtoll" on HP-UX 11.11 either.
>
> > So when I'm building, I see these errors:
>
> > gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob
> > -L./lib/tilde -L./lib/malloc -L./lib/sh-g -O2 -o bash shell.o eval.o
> > y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o
> > variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o
> > hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o
> > version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o
> > bashhist.o bashline.o siglist.o list.o stringlib.o locale.o findcmd.o
> > redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh
> > -lreadline -lhistory -lcurses -ltilde -lmalloc -lintl -ldl
> > collect2: ld terminated with signal 11 [Segmentation fault], core dumped
>
> If your linker is dumping core, you've got a problem with something more
> fundamental than bash.
>
> > general.o(.text+0x334): In function `legal_number':
> > /home/dmoore/gnu/bash-4.1/general.c:175: undefined reference to
> `__strtoll'
> > braces.o(.text+0xae4): In function `brace_expand':
> > /home/dmoore/gnu/bash-4.1/braces.c:395: undefined reference to
> `__strtoll'
> > ./builtins/libbuiltins.a(printf.o)(.text+0xe6c): In function `getintmax':
> > ./printf.def:998: undefined reference to `__strtoll'
> > make: *** [bash] Error 1
>
> This also points to a problem with your toolchain. Broken header files,
> broken linker, who knows
>
> > 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
>
> I'm using:
>
> bash-3.2# gcc -v
> Reading specs from /usr/local/lib/gcc/hppa1.1-hp-hpux11.11/3.4.6/specs
> Configured with: ../gcc-3.4.6/configure --with-gnu-as
> --with-as=/usr/local/bin/as
> Thread model: single
> gcc version 3.4.6
>
> (Yeah, I know, an hppa1.1 machine...! That was not easy to get gcc
> bootstrapped onto.)
>
> I don't know if there's a specific problem with gcc 4.0.0 on HP-UX 11.00.
> That's an awful lot of zeros, though. Things with "dot zero" on the end
> of them tend to scare me a bit.
>
> I see you're using GNU ld, which shouldn't be required on this platform.
> And also that ld is dumping core. You might try upgrading your GNU
> binutils if you want to continue using GNU ld (or even just rebuilding
> your current version); or you might try configuring gcc to use the
> system's linker.
>
> In any case, I'm pretty sure it's not a bash bug that you're running into.
>
> (If/when you run into a problem with vsnprintf, *that* is a bash bug,
> fixed in one of the 4.1 patches. You might grab the bash patches before
> your next attempt, after you get your toolchain working.)
>
Re: undefined reference to `__strtoll'
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 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 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.origThu 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 >
