Thanks, again Phill B.
Now for the really stupid questions:
1.) How do I not pull in the static libc.a; it seems my X-compiler always
adds a -la -lgcc to the link statement. gcc -v output follows:
/opt/INETlgnu/bin/armv4l-inet-linux-gcc -v -shared -o ../libtermcap.so.2.0.8
-Wl,-soname,libtermcap.so.2 termcap.o tparam.o version.o
Reading specs from
/opt/INETlgnu/lib/gcc-lib/armv4l-inet-linux/egcs-2.91.60.1/specs
gcc version egcs-2.91.60.1 19990115/Linux (egcs-1.1.1 release)
/opt/INETlgnu/lib/gcc-lib/armv4l-inet-linux/egcs-2.91.60.1/collect2 -shared
-dynamic-linker /lib/ld-linux.so.2 -X -m elf32arm -o ../libtermcap.so.2.0.8
/opt/INETlgnu/armv4l-inet-linux/lib/crti.o
/opt/INETlgnu/lib/gcc-lib/armv4l-inet-linux/egcs-2.91.60.1/crtbeginS.o
-L/opt/INETlgnu/lib/gcc-lib/armv4l-inet-linux/egcs-2.91.60.1
-L/opt/INETlgnu/armv4l-inet-linux/lib -soname libtermcap.so.2 termcap.o tparam.o
version.o -lgcc -lc -lgcc
/opt/INETlgnu/lib/gcc-lib/armv4l-inet-linux/egcs-2.91.6.1/crtendS.o
/opt/INETlgnu/armv4l-inet-linux/lib/crtn.o
2.) If bypass gcc and use ld then the troublesome R_ARM_PC24 relocs
are eliminated. However, the resulting shared lib has undefined
symbols that are not be resolved at load time. I link as follows:
$(LD) -Bdynamic -shared -o ../$@ -soname $(SONAME_SHARED_LIB) $(OBJS)
This generates dynamic relocs that are suspiciously different
when contrasted to the working libtermcap.so; the following is the diff
of the output from objdump --dynamic-reloc for my broken libtermcap
and a good libtermcap:
7,51c7,56
< 0000a078 g DO *ABS* 00000000 _DYNAMIC
< 00009ff0 g DO *ABS* 00000000 _GLOBAL_OFFSET_TABLE_
< 00009fe8 g DO .data 00000004 tgetent_bufsize
< 00000000 D *UND* 00000000 malloc
< 00000000 D *UND* 00000000 write
< 00000000 D *UND* 00000000 exit
< 00000000 D *UND* 00000000 strlen
< 00000000 D *UND* 00000000 strcpy
< 00000000 D *UND* 00000000 strncpy
< 00000000 D *UND* 00000000 strncmp
< 00000000 D *UND* 00000000 strchr
< 00000000 D *UND* 00000000 free
< 00000000 D *UND* 00000000 ioctl
---
> 0000a4ec g DO *ABS* 00000000 Base _DYNAMIC
> 0000a458 g DO *ABS* 00000000 Base _GLOBAL_OFFSET_TABLE_
> 000022e4 w DF .text 00000000 Base __gmon_start__
> 000008ac g DF .init 00000000 Base _init
> 000022f4 g DF .fini 00000000 Base _fini
> 0000a440 g DO .data 00000004 Base tgetent_bufsize
> 00000000 w DF *UND* 00000180 GLIBC_2.0 malloc
> 00000000 w DF *UND* 00000010 GLIBC_2.0 write
> 00000000 DF *UND* 00000128 GLIBC_2.0 exit
> 00000000 DF *UND* 00000060 GLIBC_2.0 strlen
> 00000000 DF *UND* 00000028 GLIBC_2.0 strcpy
> 00000000 DF *UND* 000000c0 GLIBC_2.0 strncpy
> 00000000 DF *UND* 000000f0 GLIBC_2.0 strncmp
> 00000000 DF *UND* 000000f4 GLIBC_2.0 strchr
> 00000000 w DF *UND* 000000f8 GLIBC_2.0 free
> 000021b8 g DF .text 000000d0 Base __modsi3
> 000020ec g DF .text 000000b0 Base __divsi3
> 00000000 w DF *UND* 00000010 GLIBC_2.0 ioctl
> 00000000 DF *UND* 000000a8 GLIBC_2.0 rewind
~
Philip Blundell wrote:
>
> >All the problem symbols come from libc.a (malloc, strchr, ...).
> >Does this imply that the objects in libc.a were compiled w/out -fPIC ?
>
> Yes. The static library libc.a is built without -fPIC. There is a
> performance loss in using PIC code, and it's not normally necessary unless
> shared objects are involved.
>
> Are you deliberately using the static libc rather than the shared one? If so,
> consider not doing that. :-) If not, check that you have an appropriate
> libc.so symlink in $PREFIX/lib.
>
> p.
--
Dave Baukus
Inet Technologies Inc.
[EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
