On Thu, Mar 24, 2016 at 11:21 AM, Jeffrey Walton wrote:
> On Wed, Mar 23, 2016 at 6:12 PM, Britton Kerin
> wrote:
>> I can't tell from the manual if -fPIC is safe for executable programs,
>> or only for libraries.
>>
>> I want to use -fPIC or -fPIE so dladdr() will work right. I would
>> rather use -fPIC if possible, because it seems simpler to use one such
>> option for everything if possible.
>
> You can build all your object files with -fPIC.
>
> When you build you shared library you can use the object files and:
>
> g++ -shared myobj1.o myobj2.o ... -o mylib.so
>
> When you build your program you use the same object files and:
>
> g++ -pie myobj1.o myobj2.o ... -o myprog.exe
It seems like this approach is not allowed according to the docs.
But perhaps the gcc/ld docs themselves need to be fixed. Currently in
gcc 5.3.0 docs section 3.13 Options for Linking:
-pie Produce a position independent executable on targets
that support it. For predictable results, you must also specify the
same set of options used for compilation (-fpie, -fPIE, or model
suboptions) when you specify this linker option.
...
-sharedProduce a shared object which can then be linked with
other objects to form an executable. Not all systems support this
option. For predictable results, you must also specify the same set of
options used for compilation (-fpic, -fPIC, or model suboptions) when
you specify this linker option.
which seems to preclude the arrangement you describe above: the docs
seem to be saying that -fPIC is also required at link time. Doing
that seems to work, but gcc docs section 3.18 Options for Code
Generation Conventions says:
-fpic 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 x86 has no such limit.)
Position-independent code requires special support, and therefore
works only on certain machines. For the x86, GCC supports PIC for
System V but not for the Sun 386i. Code generated for the IBM RS/6000
is always position-independent.
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
-fPIC If supported for the target machine, emit
position-independent code, suitable for dynamic linking and avoiding
any limit on the size of the global offset table. This option makes a
difference on the m68k, PowerPC and SPARC.
Position-independent code requires special support, and therefore
works only on certain machines.
When this flag is set, the macros __pic__ and __PIC__ are defined to 2.
The description of -fpic together with the existence of -fpie makes it
seem doubtful that -fpic generated code is suitable for executables,
so it's description should probably be changed somehow if it's ok to
just use -fPIC everywhere.
In GNU ld docs for binutils 2.2.6 section 2.1 Command Line Options:
-pie
--pic-executable Create a position independent executable.
This is currently only supported on ELF platforms. Position
independent executables are similar to shared libraries in that they
are relocated by the dynamic linker to the virtual address the OS
chooses for them (which can vary between invocations). Like normal
dynamically linked executables they can be executed and symbols
defined in the executable cannot be overridden by shared libraries.
No mention of the requirement to agree with compile-time options here.
Assuming the requirement for agreement applies here, it should be
mentioned as it is in the gcc docs. Perhaps the linker -pie option
isn't the same as the gcc -pie link time option, but if so that's
pretty weird and deserving of some explanation.
Unless I'm missing something I'll file gcc and binutils doc bugs for
these issues.
Britton
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
