[Patches] [ python-Patches-761969 ] -DPIC should be added for the -fPIC case

SourceForge.net noreply@sourceforge.net
Tue, 08 Jul 2003 08:52:39 -0700


Patches item #761969, was opened at 2003-06-27 19:22
Message generated for change (Comment added) made by marc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Recht (marc)
Assigned to: Nobody/Anonymous (nobody)
Summary: -DPIC should be added for the -fPIC case

Initial Comment:
AFAIK -DPIC should always added when compiling with
-DPIC.  At least that's what libtool does and shown in
many FAQs (like
http://www.netbsd.org/Documentation/elf.html).
A quick glance on NetBSD-current and FreeBSD (4.8)
shows that it's evaluated in machine/asm.h.

----------------------------------------------------------------------

>Comment By: Marc Recht (marc)
Date: 2003-07-08 17:52

Message:
Logged In: YES 
user_id=205

That's the asm.h part: (complete asm.h is attached)

#ifdef PIC
#define PIC_PROLOGUE \
   pushl %ebx; \
   call  1f;   \
1:       \
   popl  %ebx; \
   addl  $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx
#define PIC_EPILOGUE \
   popl  %ebx
#define PIC_PLT(x)   x@PLT
#define PIC_GOT(x)   x@GOT(%ebx)
#define PIC_GOTOFF(x)   x@GOTOFF(%ebx)
#else
[...]
(-DPIC seems not to be added by gcc's -fPIC.)

Note: I didn't find any functional differences (yet?). 
(Though the generated .so differs.)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-05 18:15

Message:
Logged In: YES 
user_id=21627

I completely agree with Andrew, especially in his view of
libtool. Marc, can you show us (or point us to) a fragment
of asm.h that uses -DPIC?

I would consider a system broken where -fPIC/-KPIC works
incorrectly without -DPIC. gcc is powerful enough to
automatically add this to the preprocessor if a platform
really needs it, so not supplying it would be a gcc bug. We
only work around clearly demonstrated bugs, and only by
documenting, in the Python sources, that a certain piece of
code is a work-around for a bug in some documented version
of some system.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-07-01 13:01

Message:
Logged In: YES 
user_id=250749

At least on FreeBSD, the presence or absence of -DPIC
doesn't appear to have any effect on behaviour of the built
.sos - the same ones pass/fail the tests either way,
regardless of whether the content is changed, so its not a
valuable addition.

>From what I've read, I'm not sure that libtool should be
taken as a definitive reference.


----------------------------------------------------------------------

Comment By: Marc Recht (marc)
Date: 2003-07-01 12:39

Message:
Logged In: YES 
user_id=205

So far I've only build tested it on NetBSD-current. And at
least the generated  .so differs (more than between two
builds). 
I've added this to all archs, because AFAIK that's what
libtool does, too. (And every FAQ I've looked at and also
other applications.)

Maybe configure could check if "-fPIC -DPIC" is supported by
the platform ?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-06-30 18:27

Message:
Logged In: YES 
user_id=6380

Adding -DPIC just adds a preprocessor symbol, and not a very
distinguished one. If FreeBSD really needs this particular
#define to work correctly when compiling with -fPIC, perhaps
a FreeBSD-specific patch would be acceptable.

----------------------------------------------------------------------

Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-30 12:30

Message:
Logged In: YES 
user_id=250749

I tested this patch on both FreeBSD 48 & 5.1.

AFAICT, this did not affect behaviour of the interpreter
either way.

I note that you've tagged quite a few platforms in this
patch, thus it would need to be tested on all affected
platforms to be accepted in full.

At this time, it isn't clear to me what benefits this patch
gets us.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=761969&group_id=5470