Code Comments
Programming Forum and web based access to our favorite programming groups.Hello Can any of you explain what the difference is between gcc option -fpic and -fPIC. The option -fpic works under Linux x86 but not under Mac OSX and I'd like to know why. Gcc under OS X said I should use -fPIC instead. I read the gcc documentation but didn't understand the difference between them. Both seems to make position-independent-code needed for dynamlic libraries. Thanks in advance. -- John
Post Follow-up to this messageJohn Smith <john.smith@x-formation.com> wrote: > Hello > Can any of you explain what the difference is between gcc option -fpic > and -fPIC. The option -fpic works under Linux x86 but not under Mac OSX an d > I'd like to know why. Gcc under OS X said I should use -fPIC instead. > I read the gcc documentation but didn't understand the difference between > them. > Both seems to make position-independent-code needed for dynamlic libraries.[/color ] I think reading the below carefully should make the difference clear: --- -fpic Generate position-independent code (PIC) suitable for use in a shared librar y, 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 perating system). If the GOT size for the linked executable exceeds a machi ne-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 16k on the m88k, 8k on the SPARC, and 32 k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. -fPIC If supported for the target machine, emit position-independent code, suitabl e for dynamic linking and avoiding any limit on the size of the global offset table. This option make s a difference on the m68k, m88k, and the SPARC. Position-independent code requires special support, and therefore works only on certain machines. --- Cheers, Ognen
Post Follow-up to this messageJohn Smith <john.smith@x-formation.com> wrote: > Can any of you explain what the difference is between gcc option -fpic > and -fPIC. The option -fpic works under Linux x86 but not under Mac OSX an d > I'd like to know why. Gcc under OS X said I should use -fPIC instead. > I read the gcc documentation but didn't understand the difference between > them. > Both seems to make position-independent-code needed for dynamlic libraries.[/color ] That's correct. And the difference between -fpic and -fPIC is due to the way the code is made position independent. To do that you're not allowed to have any absolute addresses in the machine code because the library will get loaded at an address that can't be forseen. Thus instead of having absolute addresses in the code such addresses are to be calculated via a so-called global offset table (GOT), so basically you have instead of an address the index in the GOT which is used for a replacement by the "real" address when the library gets loaded. For example, if you have a call to a function you normally would have some kind of jump instruction to the address where the function is located in memory. Since that wouldn't work with a shared library some an index into the GOT is stored in the shared library for that jump instruction instead and the run-time linker will replace it by the address of the function when the libary is loaded, which it can do because it knows where the library is going to be in the memory. On some systems there are certain restrictions to the size of the GOT. When there are too many symbols that require an entry in the GOT using -fpic won't work anymore on these systems and -fPIC is to be used instead to get around this limitation. Doing that will probably require some extra work during run-time linking of the library but it will work on all machines (that allow to create position-independent code). Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de
Post Follow-up to this messageJohn Smith wrote: > Hello > > Can any of you explain what the difference is between gcc option -fpic > and -fPIC. The option -fpic works under Linux x86 but not under Mac OSX an d > I'd like to know why. Gcc under OS X said I should use -fPIC instead. > I read the gcc documentation but didn't understand the difference between > them. The main question has been answered but it's worth noting that Mac OSX is one of those platforms where all code is always position independent, and therefore neither of the options mentioned has any effect. There's a slight performance hit in using pic code but, as hardware has gotten faster, some modern implementations have decided to simply take the hit in return for a simpler development model. Doesn't gcc -fpic on OSX spit out a clear diagnostic explaining this? ISTR seeing it. -- Henry Townsend
Post Follow-up to this message> The main question has been answered but it's worth noting that Mac OSX > is one of those platforms where all code is always position independent, > and therefore neither of the options mentioned has any effect. There's > a slight performance hit in using pic code but, as hardware has gotten > faster, some modern implementations have decided to simply take the hit > in return for a simpler development model. It also makes more sense to keep things simple. No normal user cares if his program takes a few milliseconds longer to load. > > Doesn't gcc -fpic on OSX spit out a clear diagnostic explaining this? > ISTR seeing it. It says that -fpic is not supported and it will use -fPIC instead. I didn't try to recompile my code without this flag because I assumed it wouldn't work like under linux. -- John
Post Follow-up to this messageOn Thu, 16 Dec 2004 17:14:19 +0000, Jens.Toerring wrote: > John Smith <john.smith@x-formation.com> wrote: ... > > On some systems there are certain restrictions to the size of the GOT. > When there are too many symbols that require an entry in the GOT using > -fpic won't work anymore on these systems and -fPIC is to be used > instead to get around this limitation. Doing that will probably require > some extra work during run-time linking of the library but it will work > on all machines (that allow to create position-independent code). Do you have any pointers to what systems exhibit what behavior ?
Post Follow-up to this messageNils O. Selåsdal <NOS@utel.no> wrote: > On Thu, 16 Dec 2004 17:14:19 +0000, Jens.Toerring wrote: > ... > Do you have any pointers to what systems exhibit what behavior ? What behaviour? That some systems have a limitation on the size of the GOT table? That's what I got from the gcc info pages where they write: 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 16k on the m88k, 8k on the SPARC, and 32k on the m68k and RS/6000. The 386 has no such limit.) That's probably why e.g. libtools seems to use -fPIC everywhere (at least as far as I can remember). Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de
Post Follow-up to this message
Show a Printable Version
Email This Page to Someone!
Receive updates to this thread
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.