Re: Fix build on freebsd-sparc

[Guy Harris <guy () alum mit edu>]

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.