Re: Python recompile

On 03/03/2025 15:03, Muttley@DastardlyHQ.org wrote:

On Mon, 3 Mar 2025 12:20:35 +0000
bart <bc@freeuk.com> wibbled:

On 03/03/2025 10:44, Muttley@DastardlyHQ.org wrote:

On Mon, 3 Mar 2025 08:31:16 +0000
Really? So if a compiler gives an error thats not a C problem? Go ask a
group for the specific compiler?

>
The errors reported by the OP were like this:
>
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
>
'ld' is a program that can be used to link programs in any language.
>
The problem appears to be do with generating position independent code
since these days linkers like to generate programs that can loaded at an
arbitrary address in high memory.
>
I can't see anything to do with C here, other than the source in
question may have been written in C.

 Yes, thats kind of the point. You wouldn't get these errors if it was written
in Java or C#.

Why not? There would be the same issues with position-independent code. Maybe they just come up elsewhere, or maybe the problem is taken care of inside the tool.
Take this example:
   c:\mx>mm -obj hello
   Compiling hello.m to hello.obj
   c:\mx>ld hello.obj
   hello.obj:hello.obj:(.text+0x4e05): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.data'
It's a similar kind of linker issue. But the language here isn't C. I can make it C:
   c:\cx>bcc -c hello.c
   Compiling hello.c to hello.obj
   c:\cx>ld hello.obj
   hello.obj:hello.obj:(.text+0x7): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32 against `.data'
Exactly the same error, one for language C, and one for language 'M'.
So you still think it's to do with the C language only?
Here, I tweaked both compilers to disable the high-loading flag when generating object files, in order to force the error, because normally it knows to set it for those file types.
So it's to do with the compiler backend, but such backends tend to be used for multiple languages: gcc can be used for multiple front-end languages, as can LLVM used by clang.
And the solution will likely be to do with the build system: you don't build CPython by manually invoking gcc with your own options. It's a quite elaborate process.
Presumably the official build system works, so the OP is doing something different.
I very much doubt that whatever it is can be fixed by modifying the C sources.

[snip]
 

On usenet? That is pretty much dead.

 Not dead but certainly not buzzing yet

It was buzzing in the 1990s but has been gradually dying. This group is an oasis; the rest of it is either a wasteland or a cesspit, or has been taken over by nutters.

I presume thats how you like it given
you don't want any "everyday development issues" relating to C mentioned here.
 Or are you another one who thinks usenet should be for the exclusive discussion
of high brow issues only of interest to you?

I'm pointing out why this is probably not on topic. Personally I don't care.