Re: Python recompile

In comp.lang.c James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 3/2/25 12:54, Waldek Hebisch wrote:

In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:

How do I compensate for
>
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC

defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
              thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a

>

 
This is real world question and as such is considered off-topic
in comp.lang.c.  However, you could try '-no-pie' to the compiler.

 
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
 
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.

The question is about C implementation.  Namely, the bible for
this group, that is C standard requires C implementation to
produce executables.  And making executable from C sources
it at core of the OP question.  Fact that compiling this source
is supposed to produce Python interpreter or maybe some
supporting shared library is irrelevant here.

One could call the problem "Linux problem".  Namely, many
(maybe all) Linux distribution modify(ed) gcc so that creating
position independent executables is the default and to
prevent this one need '-no-pie' at final stage.  And to
generate position independent executable all code has to
be compiled as position independent code which needs '-fPIC'
option.  Similarly, if OP is trying to create shared
library, then on Linux all code inluded in the shared
librayr must be compiled as position independent code,
that is using '-fPIC'.

Dismissing this as linker problem misses important
points:
- linking is considerd part of C implementation
- '-fPIC' is option for compiler proper
- '-no-pie' is handled by the compiler driver
 
And frankly, making executables or shared library from
C code is real world thing that C programmer want to do
and non-programmers would not do.

OP uses some build system and fixing his problem presumably
needs changes to build system.  And reasonably build system
may be cosidered of topic here.  However, fact that compilation
proper and final linking must use consitent options is
real world C problem.  I appreciate that many years ago
comp.lang.c regulars decided that they do not want to answer
such real world question.  However, do you want to tell OP
"pretend that your main program is in Fortran and ask your
question in comp.lang.fortran"?  FYI, similar questions were
asked and answered in comp.lang.fortran without questioning
topicality.  So clearly, the only thing which makes such
question of topic here is past deliberate decision to exclude
them.

--
                              Waldek Hebisch