Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Mon, 03 Mar 2025 17:59:38 -0800
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <86jz95v9md.fsf@linuxsc.com>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq260p$u8ub$1@paganini.bofh.team> <vq2j3n$v2fk$1@dont-email.me> <vq4ocv$17dal$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 04 Mar 2025 02:59:38 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c23ef12ecffd36b31ef4d9528ea72cba";
	logging-data="1654828"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19y3ShY9fM88HVpI6CE4/tifFKPd4uk/0k="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:wD65WDAq1kKCdumjtZvuwI0fzu4=
	sha1:90XYHF28Gd9LVTVksZsiJcsyINA=
Bytes: 3280

antispam@fricas.org (Waldek Hebisch) writes:

> 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.

Actually it doesn't.  The C standard does require implementations
to gather translator output into a program image that has the
information needed to execute the program in its execution
environment, but the standard doesn't say what that program image
is.  In fact the C standard says specifically that the mechanism
by which C programs are invoked for use by a data-processing
system is outside the scope of what the standard specifies.
There is no reason the execution environment couldn't be some
sort of interpreted environment, and no reason the invocation
mechanism couldn't be some sort of interpreter acting on the
program image.