Philip is right again,
I did not have libc.so. I had libc-2.1.so an libc.so.6; after adding
another symlink I can build shared libraries.
But, wouldn't ya know, now any program that uses stat() and friends
fails to compile w/
/tmp/cce1Dcuw.o: In function `main':
/tmp/cce1Dcuw.o(.text+0x24): undefined reference to `stat'
collect2: ld returned 1 exit status
As far as I can tell stat() is only in libc.a and now w/ my
libc.so symlink in place it seems the linker refuses to look
into libc.a.
Philip Blundell wrote:
>
> Hi Dave,
>
> > 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:
>
> If you have a libc.so available to the linker, it ought to use that in
> preference to the .a file. You should have had one installed with glibc -
> it's a short text file and it should live in the same directory that libc.a
> does, probably /opt/INETlgnu/armv4l-inet-linux/lib in your case. Can you
> check whether that's the case?
>
> > 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:
>
> Yeah. This is a road to ruin - don't go there. If you go behind the
> compiler's back you need to be pretty sure you know what you're doing,
> otherwise you will just dig yourself a deeper hole. There is virtually never
> a good reason to use ld directly rather than gcc with appropriate options.
>
> p.
--
Dave Baukus
Inet Technologies Inc.
[EMAIL PROTECTED]
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
