[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PIE support
Re: PIE support
Thu, 1 Dec 2005 10:43:03 +0000 (GMT)
On Wed, 30 Nov 2005, Ralf Wildenhues wrote:
Because: when one day 100 compilers support this, they may use 10
different #defines for this notion. Or not, who knows.
Sure. Then you should possibly also define __PIC__ for completeness /
symmetry? (relying on gcc to provide that at present right?)
Yes, but most packages using libtool won't ever need to compile a
PIC object without libtool's help. Unlike PIE, when you do
CFLAGS=-fpie. Which in turn is what we're trying to settle on,
currently. (Well, I am at least ;)
Sure. As long as you stick with GCC and GNU ld, there won't be any
issues. If libtool were to specialize on those two only, it'd be
fair to say there is little point in having a thing such as libtool
Well, the more interesting question would probably be the GNU ld version
you used, and on what hardware.
x86. GNU ld 2.9.1 and also 2.15. Thing is, I'm not sure gcc actually
used GNU ld. If I do:
LD=gld gcc ....
The binary works.
If I manually compile to object code with gcc and then link by hand
with gld, it segfaults:
$ gcc -c -fpie -pie -Os test.c -o test.o -lc -lnsl -lsocket
$ gld -fpie -lc -lnsl -lsocket -o test test.o
It segfaults if I use Solaris ld by hand too, so I must be doing
In no case, where I let gcc handle linking, do I get anything that is
obviously a relocatable executable though. (variables in main are at
same location on each invocation).
I could not find such discussion (I searched before reporting the bug
upstream). Could you point me to it? Thanks.
I can't I'm afraid. It came up when talking to the user who
desperately wanted an easier way to build our project's daemons as
PIE, I can't find the URL back though. :(
Paul Jakma address@hidden address@hidden Key ID: 64A2FF6A
I'm not a real movie star -- I've still got the same wife I started out
with twenty-eight years ago.
-- Will Rogers
- Re: PIE support,
Paul Jakma <=