On May 9, 2010, at 2:24 AM, Guy Harris wrote:
>
> On May 9, 2010, at 2:11 AM, Peter Volkov wrote:
>
>> It was reported that libpcap fails to link on freebsd-sparc:
>> http://bugs.gentoo.org/show_bug.cgi?id=247076
>>
>> Patch in attachment fixes this issue. Please, apply.
>
> Is SPARC the only architecture that requires -fPIC? (On what architectures
> does the code generated by -fpic and by -fPIC differ?)
According to
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Code-Gen-Options.html#Code-Gen-Options
it only makes a difference on 68K, PowerPC^H^H Architecture, and SPARC. I
suspect that, on most if not all platforms that had or have System V-style
ABIs, GCC uses that style of PIC, so other compilers that generate PIC probably
generate the same type of PIC, so - modulo generating smaller code that doesn't
overflow the lower-case-pic offset field - they might have the same issue.
Also, according to that page:
Generate position-independent code (PIC) suitable for use in a shared
library, if supported for the target machine. Such code accesses all constant
addresses through a global offset table (GOT). The dynamic loader resolves the
GOT entries when the program starts (the dynamic loader is not part of GCC; it
is part of the operating system). If the GOT size for the linked executable
exceeds a machine-specific maximum size, you get an error message from the
linker indicating that -fpic does not work; in that case, recompile with -fPIC
instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000.
The 386 has no such limit.)
("RS/6000"? Nobody makes RS/6000's any more; they're now System p or whatever
the heck IBM calls them. :-))
I'll assume for now that the larger maximum GOT size means it's not an issue
for 68K or PPC (and that, the rather ancient reference to RS/6000's
nonwithstanding, the GCC documentation correctly enumerates the architectures
that have two style of PIC).
The link fails when trying to refer to a symbol in libc; is the underlying
"problem" that there are too many data symbols in libc for lower-case-pic code
that uses libc to work? (I put "problem" in quotes because it's not really a
bug, although it might be nice if it could be "fixed" without losing libc
functionality or hurting performance more than using lower-case-pic rather than
capital-PIC code would help it.)
Does this problem exist on other OSes? (This is a gentoo report - is this "on
freebsd-sparc" or "on
freebsd-kernel-and-Gentoo-Linux-userland-ported-to-freebsd-kernel-sparc"?)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
