This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: -DPIC should be added for the -fPIC case
Type: Stage:
Components: None Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: aimacintyre, gvanrossum, loewis, marc
Priority: normal Keywords: patch

Created on 2003-06-27 17:22 by marc, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
configure.in-pic.diff.gz marc, 2003-06-27 17:22 configure.in patch
asm.h marc, 2003-07-08 15:52 NetBSD-current/x86 asm.h
Messages (8)
msg44131 - (view) Author: Marc Recht (marc) Date: 2003-06-27 17:22
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.
msg44132 - (view) Author: Andrew I MacIntyre (aimacintyre) * (Python triager) Date: 2003-06-30 10:30
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.
msg44133 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-06-30 16:27
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.
msg44134 - (view) Author: Marc Recht (marc) Date: 2003-07-01 10:39
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 ?
msg44135 - (view) Author: Andrew I MacIntyre (aimacintyre) * (Python triager) Date: 2003-07-01 11:01
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.
msg44136 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-05 16:15
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.
msg44137 - (view) Author: Marc Recht (marc) Date: 2003-07-08 15:52
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.)

msg44138 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-08 21:14
Logged In: YES 
user_id=21627

I see. Rejecting this patch: We never ever use PIC_PROLOGUE,
PIC_PLT, or any macros that are based on them.
History
Date User Action Args
2022-04-10 16:09:28adminsetgithub: 38726
2003-06-27 17:22:16marccreate