Discussion:
Python recompile
(too old to reply)
The Doctor
2025-03-02 14:35:08 UTC
Permalink
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
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:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32S cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
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:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
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:140 (Python/thread_pthread.h:140)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32S cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(thread.o)
referenced by thread_pthread.h:290 (Python/thread_pthread.h:290)
thread.o:(do_start_joinable_thread) in archive /usr/local/lib/libpython3.13.a
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_get_thread_ident_ex) in archive /usr/local/lib/libpython3.13.a
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:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_get_thread_ident_ex) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32S cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_get_thread_ident_ex) in archive /usr/local/lib/libpython3.13.a
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_get_thread_ident) in archive /usr/local/lib/libpython3.13.a
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:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_get_thread_ident) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32S cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_get_thread_ident) in archive /usr/local/lib/libpython3.13.a
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_get_thread_native_id) in archive /usr/local/lib/libpython3.13.a
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:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_get_thread_native_id) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32S cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_get_thread_native_id) in archive /usr/local/lib/libpython3.13.a
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_allocate_lock) in archive /usr/local/lib/libpython3.13.a
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:140 (Python/thread_pthread.h:140)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32S cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:141 (Python/thread_pthread.h:141)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
ld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(thread.o)
referenced by thread_pthread.h:441 (Python/thread_pthread.h:441)
thread.o:(PyThread_allocate_lock) in archive /usr/local/lib/libpython3.13.a
ld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
--
Member - Liberal International This is ***@nk.ca Ici ***@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
Ontario vote for the Liberals - The best Anti-Trump option!
Lew Pitcher
2025-03-02 15:54:19 UTC
Permalink
First off, this isn't really on-topic for comp.lang.c, as it is a question regarding a linker, interacting
with the results of various options given to a specific compiler.

However...
Post by The Doctor
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
The error message tells you exactly how to fix the problem: recompile the module using the
-fPIC
option to the compiler. -fPIC tells your compiler to generate a specific type of position-independant
code, which your linker (apparently) requires for a specific type of relocation.


[snip]

HTH
--
Lew Pitcher
"In Skills We Trust"
M***@dastardlyhq.com
2025-03-02 16:58:20 UTC
Permalink
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group? No? Then its a perfectly valid post.
Lew Pitcher
2025-03-02 17:08:33 UTC
Permalink
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
That wouldn't even make sense. What you want is a group like
the comp.unix hierarchy (for ld, as a tool), or gnu.gcc.help
(or even gnu.misc.discuss), or even comp.programming.

Your issue isn't a C language or C usage issue, it's a
"What options do I give this particular compiler in order
to satisfy the requirements of this particular linker?" issue.
Post by M***@dastardlyhq.com
No? Then its a perfectly valid post.
Yes. Somewhere else.

--30--
--
Lew Pitcher
"In Skills We Trust"
M***@DastardlyHQ.org
2025-03-03 08:14:55 UTC
Permalink
On Sun, 2 Mar 2025 17:08:33 -0000 (UTC)
Post by Lew Pitcher
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
That wouldn't even make sense. What you want is a group like
the comp.unix hierarchy (for ld, as a tool), or gnu.gcc.help
(or even gnu.misc.discuss), or even comp.programming.
I don't want any group, it wasn't my problem. And using your logic how is
comp.programming and more related to linker issues than comp.lang.c?
Post by Lew Pitcher
Your issue isn't a C language or C usage issue, it's a
"What options do I give this particular compiler in order
to satisfy the requirements of this particular linker?" issue.
So compiling C has nothing to do with C? Riiiight.
James Kuyper
2025-03-02 17:30:53 UTC
Permalink
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
Scott Lurndal
2025-03-02 18:35:31 UTC
Permalink
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
Frankly, I'd rather read about issues in the linker here than the
interminable useless arguments about the precision and accuracy of
fmod, which belong elsewhere (such as email), or pointless musings
about the halting problem.
M***@DastardlyHQ.org
2025-03-03 08:13:04 UTC
Permalink
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C. That sounds like a C issue to me.
Richard Heathfield
2025-03-03 08:31:16 UTC
Permalink
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.

It's an old argument, but it has never been a good one.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C. That sounds like a C issue to me.
Then you have very gullible ears. Building the Python source is
an issue for a specific compiler group.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DastardlyHQ.org
2025-03-03 10:44:08 UTC
Permalink
On Mon, 3 Mar 2025 08:31:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.
It's an old argument, but it has never been a good one.
Really? So if a compiler gives an error thats not a C problem? Go ask a
group for the specific compiler?

What a load of narrow minded BS. Its not as if these groups get hundreds of
messages a day and the amount needs to be cut down.
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C. That sounds like a C issue to
me.
Then you have very gullible ears. Building the Python source is
No idea what gullible ears is supposed to mean.
Post by Richard Heathfield
an issue for a specific compiler group.
So which group would that be then?
bart
2025-03-03 12:20:35 UTC
Permalink
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 08:31:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.
It's an old argument, but it has never been a good one.
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.
Post by M***@DastardlyHQ.org
What a load of narrow minded BS. Its not as if these groups get hundreds of
messages a day and the amount needs to be cut down.
Personally I'm not bothered, and would have answered if I could; I think
some already have.

For a broader C forum, which is more tolerant than this one even though
it is moderated, the OP could try the C_Programming subreddit of Reddit.

The question also seems a good fit for Stack Exchange.

There may even be specialist forums for building or developing CPython.

(Over a decade ago, I myself had a problem in building CPython on
Windows. I posted about in comp.lang.python, but they were *******
useless. People there only knew how to write Python programs.)

I expect however you'd be OK with this forum being full of everyday
development issues associated with a million different applications, but
which just happen to be written in C, or which are partly in C.
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C. That sounds like a C issue to
me.
Then you have very gullible ears. Building the Python source is
No idea what gullible ears is supposed to mean.
Post by Richard Heathfield
an issue for a specific compiler group.
So which group would that be then?
On usenet? That is pretty much dead.
M***@DastardlyHQ.org
2025-03-03 15:03:20 UTC
Permalink
On Mon, 3 Mar 2025 12:20:35 +0000
Post by The Doctor
Post by M***@DastardlyHQ.org
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?
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#.
Post by The Doctor
I expect however you'd be OK with this forum being full of everyday
development issues associated with a million different applications, but
which just happen to be written in C, or which are partly in C.
[snip]
Post by The Doctor
On usenet? That is pretty much dead.
Not dead but certainly not buzzing yet 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?
Richard Heathfield
2025-03-03 12:47:21 UTC
Permalink
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 08:31:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
And without people to write it and buildings in which to work it
wouldn't even be that, so by your argument everything from
demographics to urban planning would be topical here.
It's an old argument, but it has never been a good one.
Really?
Really.
Post by M***@DastardlyHQ.org
So if a compiler gives an error thats not a C problem?
The compiler isn't a C problem. The code that prompted the error
can be.
Post by M***@DastardlyHQ.org
Go ask a
group for the specific compiler?
If the question is about the compiler, yes.

If the question is about C code, they will properly redirect you
here.
Post by M***@DastardlyHQ.org
What a load of narrow minded BS.
Why don't you cut to the chase and say something bad about my
mother? The fact that you don't understand topicality does not
invalidate the concept of topicality.
Post by M***@DastardlyHQ.org
Its not as if these groups get hundreds of
messages a day and the amount needs to be cut down.
The groups where the question is topical do not get hundreds of
messages a day either. Why steal their questions?
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C. That sounds like a C issue to
me.
Then you have very gullible ears. Building the Python source is
No idea what gullible ears is supposed to mean.
I'm sorry. I'll dial back the rhetoric for you.

Building Python source not C question. Capisce?
Post by M***@DastardlyHQ.org
an issue for a specific compiler group.
So which group would that be then?
No idea. But we're crossposted to comp.lang.python, who may be
willing to give you a hint.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
James Kuyper
2025-03-03 15:22:10 UTC
Permalink
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.

That sounds like a C issue to me.

If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
M***@DastardlyHQ.org
2025-03-03 16:19:55 UTC
Permalink
On Mon, 3 Mar 2025 10:22:10 -0500
Post by James Kuyper
Post by M***@DastardlyHQ.org
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Your reducto ad absurdum analogy is just that - absurd.

Failure to link object files created by a C compiler is very much a C problem
eg in some cases though maybe not this it may be down to missing "extern"
keywords in certain C source files. Either way it means the compiler has
not created the correct object files from the source.

Unless you're going to claim that C programming ends at the editor and
compilation has nothing to do with it.
Post by James Kuyper
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
In other news - the lack of electrons in the battery of a car thats failing to
start are nothing to do with the car and hence not a maintenance issue.
geodandw
2025-03-03 16:24:13 UTC
Permalink
Post by James Kuyper
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
M***@DastardlyHQ.org
2025-03-03 16:26:54 UTC
Permalink
On Mon, 3 Mar 2025 11:24:13 -0500
Post by geodandw
Post by James Kuyper
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
For as long as usenet has been around there have been people trying to
surreptitiously control groups and limit the valid topics to those which they
think are appropriate, whether others share their opinions or not. Usually IME
these people are on the spectrum.
James Kuyper
2025-03-03 16:39:58 UTC
Permalink
...
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
responded to by people who are more likely to understand and be
interested in the contents of the message, and can give you better
answers to any questions you have. When you post to the wrong group,
they will be less interested in the message and less capable of giving
good answers to it.
However, if you're not interested in getting good answers to your
questions, and it doesn't bother you that your messages are going to
people not interested in the topic of your message, by all means post to
any group you choose. This isn't a moderated group - no one can stop you
from posting here.
M***@DastardlyHQ.org
2025-03-03 16:56:37 UTC
Permalink
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
David Brown
2025-03-03 17:22:52 UTC
Permalink
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
If the problem could be solved by understanding C better, it would be
relevant. But the problem has nothing to do with the C /code/ in
question, nor the C language. It's a matter of the build process for
the particular program - not a C issue. It is not even a linker issue,
or a "make" issue. It is an issue with the program source and build
process, which is very specific to the program in question.

That means people who are experts on the C language, and experts at C
coding, can't help the OP - no matter how much they would like to help.

Thus it is off-topic.

Of course it is possible that someone in this group is familiar with
building Python, or with similar errors in building other programs - so
it's maybe worth trying posting here. But if unless the OP gets lucky
like that, the best people here can do is give suggestions for other
sources of help - and then the thread can stop as it is not only
off-topic, but very niche. The same goes for posting in
comp.lang.python - amongst the Python users there who have no clue about
the problem, there might happen to be people who have compiled Python
themselves.

Probably the best place for the OP to look would be in the C-Python
developer documentation, or groups, forums or mailing lists connected to
that.


For the obligatory car metaphor, imagine a group dedicated to learning
to drive and driving techniques. A post about a particular make of car
would be off-topic, but perhaps okay on occasion. The OP's post here is
asking for the best way to avoid roadworks on the Bath to Reading road.
Maybe he'll get lucky and someone in the group knows that area, but for
the most part, all the group can do is direct him to other sources of
information - despite the fact that he is driving.
M***@DastardlyHQ.org
2025-03-04 08:31:03 UTC
Permalink
On Mon, 3 Mar 2025 18:22:52 +0100
Post by David Brown
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
If the problem could be solved by understanding C better, it would be
relevant. But the problem has nothing to do with the C /code/ in
question, nor the C language. It's a matter of the build process for
Compilation is a fundamental part of developing in C.
Post by David Brown
For the obligatory car metaphor, imagine a group dedicated to learning
to drive and driving techniques. A post about a particular make of car
would be off-topic, but perhaps okay on occasion. The OP's post here is
asking for the best way to avoid roadworks on the Bath to Reading road.
Lousy metaphor. Its more like writing C code is building the car and
compilation is starting it up at the end.
Kaz Kylheku
2025-03-04 17:28:04 UTC
Permalink
Post by M***@DastardlyHQ.org
Compilation is a fundamental part of developing in C.
Someone trying to build a open source package like Python isn't
ipso facto confirmed to be "developing in C".
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Richard Heathfield
2025-03-03 17:25:27 UTC
Permalink
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
James Kuyper has been posting here for decades, and has helped
many hundreds, or more likely thousands, of C programmers to
better understand the C language. A genuine language expert, he
deserves to be treated better than to be called an arrogant
idiot, especially when the abuser has no discernible track record
of having ever helped anyone with high quality C advice.

That may be because "Muttley" doesn't seem even to know what the
C language /is/.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DastardlyHQ.org
2025-03-04 08:32:17 UTC
Permalink
On Mon, 3 Mar 2025 17:25:27 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
James Kuyper has been posting here for decades, and has helped
Oh well, in that case I bow down in front of his magnificence, he must not
be contradicted!
Post by Richard Heathfield
many hundreds, or more likely thousands, of C programmers to
better understand the C language. A genuine language expert, he
deserves to be treated better than to be called an arrogant
idiot, especially when the abuser has no discernible track record
of having ever helped anyone with high quality C advice.
That may be because "Muttley" doesn't seem even to know what the
C language /is/.
Compilation is a fundamental part of the process of programming in C whether
you and Kuyper like it or not.
Richard Heathfield
2025-03-04 08:56:57 UTC
Permalink
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 17:25:27 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
James Kuyper has been posting here for decades, and has helped
Oh well, in that case I bow down in front of his magnificence, he must not
be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.

Here, he is not mistaken. You are.
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
many hundreds, or more likely thousands, of C programmers to
better understand the C language. A genuine language expert, he
deserves to be treated better than to be called an arrogant
idiot, especially when the abuser has no discernible track record
of having ever helped anyone with high quality C advice.
That may be because "Muttley" doesn't seem even to know what the
C language /is/.
Compilation is a fundamental part of the process of programming in C whether
you and Kuyper like it or not.
Quoth K&R in "The C Programming Language":

Just how to run this program depends on the system you are using.
As a specific example, on the UNIX operating system you must
create the program in a file whose name ends in ".c", such as
hello.c, then compile it with the command cc hello.c... On other
systems, the rules will be different; check with a local expert.


And that's the point. The OP needs a local expert - i.e. someone
who has specific experience of building Python with the OP's
specific compiler.

K&R go on (on p25): "If the source program appears in several
files, you may have to say more to compile and load it than if it
all appears in one, but that is an operating system matter, not a
language attribute."
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DastardlyHQ.org
2025-03-04 09:23:24 UTC
Permalink
On Tue, 4 Mar 2025 08:56:57 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Oh well, in that case I bow down in front of his magnificence, he must not
be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.
Here, he is not mistaken. You are.
No, I'm not, because plenty of compilation issues are caused by code issues.
Or are you claiming those don't count as part of development?
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Compilation is a fundamental part of the process of programming in C whether
you and Kuyper like it or not.
*yawn*
Post by Richard Heathfield
Just how to run this program depends on the system you are using.
As a specific example, on the UNIX operating system you must
Blah blah.

K&R would also claim that the function parameter type definitions have to
follow the prototype. Luckily that hasn't been the case since 1989.
Richard Heathfield
2025-03-04 09:57:16 UTC
Permalink
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 08:56:57 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Oh well, in that case I bow down in front of his magnificence, he must not
be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.
Here, he is not mistaken. You are.
No, I'm not,
Yes, you are.
Post by M***@DastardlyHQ.org
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
Post by M***@DastardlyHQ.org
Or are you claiming those don't count as part of development?
Not at all. Your keyboard's shift key is part of development too,
but that isn't enough to make it topical in comp.lang.c.

Show us the code.
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Compilation is a fundamental part of the process of programming in C whether
you and Kuyper like it or not.
*yawn*
Post by Richard Heathfield
Just how to run this program depends on the system you are using.
As a specific example, on the UNIX operating system you must
Blah blah.
K&R would also claim that the function parameter type definitions have to
follow the prototype. Luckily that hasn't been the case since 1989.
Is it, then, your claim that K&R are mistaken or outdated and
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?

If you think you can defend your claim by showing where the
language standard supports your extraordinarily wobbly position,
by all means have a crack at it. Show us why you're right.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DastardlyHQ.org
2025-03-04 10:03:29 UTC
Permalink
On Tue, 4 Mar 2025 09:57:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems. Do you
get someone else to compile your code for you?
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Or are you claiming those don't count as part of development?
Not at all. Your keyboard's shift key is part of development too,
but that isn't enough to make it topical in comp.lang.c.
Oh dear, if stuck go in circles, posted comparisons conveniently ignored.
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
K&R would also claim that the function parameter type definitions have to
follow the prototype. Luckily that hasn't been the case since 1989.
Is it, then, your claim that K&R are mistaken or outdated and
Is K&R outdated? Hmm, let me think about that for a nanosecond...
Post by Richard Heathfield
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
A compiler is a compiler, a linker is a linker. Troubleshooting both is part
of the development process of any competent C dev. But we know already you
don't consider that to be the case because its beyond your abilities.
Post by Richard Heathfield
If you think you can defend your claim by showing where the
language standard supports your extraordinarily wobbly position,
by all means have a crack at it. Show us why you're right.
Wtf has the language standard got to do with anything? Moving goalposts, much?
Richard Heathfield
2025-03-04 10:25:01 UTC
Permalink
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 09:57:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems.
No, that's not what I'm saying. Do learn to read. What I'm saying
is that the OP would be better served by posting the problem
statement in a group more closely related to the actual problem.

We may, I trust, presume that the Python source he is building is
production code that has successfully been built before by other
people? If so, then it's not a language issue, and that is enough
to put it beyond comp.lang.c's brief.
Post by M***@DastardlyHQ.org
Do you
get someone else to compile your code for you?
I tell the compiler to do it. Don't you?
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Or are you claiming those don't count as part of development?
Not at all. Your keyboard's shift key is part of development too,
but that isn't enough to make it topical in comp.lang.c.
Oh dear, if stuck go in circles, posted comparisons conveniently ignored.
Your inability to comprehend analogies does not stop them from
being valid illustrations of the gaping holes in your "argument"
(such as it is).
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
K&R would also claim that the function parameter type definitions have to
follow the prototype. Luckily that hasn't been the case since 1989.
Is it, then, your claim that K&R are mistaken or outdated and
Is K&R outdated? Hmm, let me think about that for a nanosecond...
So it *is* your claim that...
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
Laughing my socks off. Time to plonk, perhaps?
Post by M***@DastardlyHQ.org
Wtf has the language standard got to do with anything?
Yep; time to plonk.

Bye-bye.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DastardlyHQ.org
2025-03-04 11:19:35 UTC
Permalink
On Tue, 4 Mar 2025 10:25:01 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 09:57:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems.
No, that's not what I'm saying. Do learn to read. What I'm saying
Sounds like it to me.
Post by Richard Heathfield
is that the OP would be better served by posting the problem
statement in a group more closely related to the actual problem.
Well do feel free to suggest which group might be appropriate for C compilation
issues.
Post by Richard Heathfield
We may, I trust, presume that the Python source he is building is
production code that has successfully been built before by other
people? If so, then it's not a language issue, and that is enough
to put it beyond comp.lang.c's brief.
There's zero logical connection there. People experience similar issues all
the time with C, should they all be denied help?
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
get someone else to compile your code for you?
I tell the compiler to do it. Don't you?
You sure you don't get someone else to run the compiler for you?
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Oh dear, if stuck go in circles, posted comparisons conveniently ignored.
Your inability to comprehend analogies does not stop them from
being valid illustrations of the gaping holes in your "argument"
(such as it is).
Translation: I have no counter argument worth a damn.

As expected.
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Is K&R outdated? Hmm, let me think about that for a nanosecond...
So it *is* your claim that...
Their language spec is certainly outdated. You think its current?
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
Laughing my socks off. Time to plonk, perhaps?
Laughing at your own replies now? Well at least we can agree they are
laughable.
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Wtf has the language standard got to do with anything?
Yep; time to plonk.
Oh dear, really can't argue your way out of a wet paper bag can you so
resort to the standard issue lost the argument last resort of drop-the-mic.
Post by Richard Heathfield
Bye-bye.
Good riddance.
Kaz Kylheku
2025-03-04 17:42:27 UTC
Permalink
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 09:57:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems. Do you
get someone else to compile your code for you?
Python is not "your code" for any value of "your" referring to any
regular here in comp.lang.c.
Post by M***@DastardlyHQ.org
A compiler is a compiler, a linker is a linker. Troubleshooting both is part
of the development process of any competent C dev. But we know already you
don't consider that to be the case because its beyond your abilities.
Troubleshooting an open source package build problem is often a complex
problem that in most cases requires direct access to the environment
where the problem is happening.

It's actually a case of porting. When Python does not build in some OS
distro with certain compilers, that's a kind of porting challenge.

The program in question almost certainly doesn't have a C language
problem. It has a build system portability problem. Even though
some build system portability problems intersect with C topics, This
isn't a build system portability problem newsgroup.

"Port this big package for me to my environment because I don't know
what I'm doing" is not a suitable discussion topic here for reasons like
people not having that exact environment ot be able to reproduce the
problem, and people not coming here to discuss that sort of thing.

It's a lot better to take it to either a mailing list for the platform
where you are trying to port the program, or else the mailing list for
that program.

The build issue could be something that recurs for other programs
being ported to the same environment.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
bart
2025-03-04 18:16:25 UTC
Permalink
Post by Kaz Kylheku
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 09:57:16 +0000
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
because plenty of compilation issues are caused by code issues.
Undoubtedly true, and equally undoubtedly irrelevant in this
case. Were it relevant, the OP would by now have shown us the
problem code.
So what you're saying is you can't troubleshoot linking problems. Do you
get someone else to compile your code for you?
Python is not "your code" for any value of "your" referring to any
regular here in comp.lang.c.
Post by M***@DastardlyHQ.org
A compiler is a compiler, a linker is a linker. Troubleshooting both is part
of the development process of any competent C dev. But we know already you
don't consider that to be the case because its beyond your abilities.
Troubleshooting an open source package build problem is often a complex
problem that in most cases requires direct access to the environment
where the problem is happening.
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
job appears to be generate the necessary makefiles. I see options like
"-fPIC" inside it set according to platform type and other settings.


Maybe the OP was trying to build it independently. I tried it once on
Windows; I was told by the people at comp.lang.python that it was a
piece of cake; it wasn't. (I notice this is cross-posted there; I will
keep that in.)

On Windows, CPython must be built via MSVC, not gcc.

That involving installing VS20xx, a 6GB download, which itself first
needed a 4GB .NET update. Then I needed GIT. Then SVN. Then MSBUILD
tools. Then something else...

Whatever I fixed, it always found something else to fail on. After
several hours and a lot of downloads, I gave up.
Post by Kaz Kylheku
It's actually a case of porting. When Python does not build in some OS
distro with certain compilers, that's a kind of porting challenge.
Yet CPython exists on Windows; it must work for somebody!

I'd been interested in fiddling with the source to make it faster, but
the first thing I discovered was that on Linux, CPython makes use of
gcc's extensions to use computed-gotos for its dispatch loop.

MSVC doesn't have that feature, so on Windows, CPython is a little bit
slower than on Linux as it has to use a regular 'switch', because the
developers couldn't manage to build it with gcc on Windows.
M***@DastardlyHQ.org
2025-03-05 09:10:21 UTC
Permalink
On Tue, 4 Mar 2025 18:16:25 +0000
Post by bart
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup. OS specific code
should be dealt with some appropriate ifdefs in the source and libraries
and linking should be a few 10s of lines.

Back in the day packages used to hve different preprepared Makefiles for
each system they could build on and IME that tended to work a lot better
than configure scripts that tried to figure things out on the fly.
Waldek Hebisch
2025-03-06 19:21:45 UTC
Permalink
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 18:16:25 +0000
Post by bart
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup. OS specific code
should be dealt with some appropriate ifdefs in the source and libraries
and linking should be a few 10s of lines.
Back in the day packages used to hve different preprepared Makefiles for
each system they could build on and IME that tended to work a lot better
than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
bigger and more complicated, so such hand editing is too much work
for rare people capable of doing this.

Per platform Makefile-s do not scale when one wants to support
multiple system and multiple configurations (there is exponential
growth of possible combinations). And even of single configuration
for supposedly single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files
where x represented one Linux flavour. Yet regularly somebody
would come and say: "build fails on my Linux x.y.z". If enough
information was provided new Makefile was added, or possibly
some similar Makefile was modified to cover more cases.
Those troubles mostly vanished when project switched to configure
script. Now there is about 1500 lines of hand written code
in configure machinery (biggest is 933 lines long configure.ac)
and 8564 lines long generated configure script. Most build
troubles is now gone or diagnosed early.

Writing "diagnosed early" I mean that most user errors are
detected quite early. For example, a lot of people try to
compile program without having a C compiler. And when they
have compiler they fail to install needed libraries (there
is list which says what is needed but people fail to follow
instructions).

It is certainly silly when generated configure file is much
bigger than actual program code. This happens frequently
when lazy or brainwashed folks use automake (which apparently
puts all checks that it knows into generated configure.ac).
But Python have reasons to check for a lot of things, so
the size is somewhat reasonable.
--
Waldek Hebisch
M***@DastardlyHQ.org
2025-03-07 09:53:37 UTC
Permalink
On Thu, 6 Mar 2025 19:21:45 -0000 (UTC)
Post by Waldek Hebisch
Post by M***@DastardlyHQ.org
On Tue, 4 Mar 2025 18:16:25 +0000
Post by bart
The CPython source bundle doesn't come with any makefiles. The first
step appears to be to run a 35,000-line 'configure' script. Part of its
Frankly any build system that has a 35K configure file needs revisiting.
No package is so complex as to require that much setup. OS specific code
should be dealt with some appropriate ifdefs in the source and libraries
and linking should be a few 10s of lines.
Back in the day packages used to hve different preprepared Makefiles for
each system they could build on and IME that tended to work a lot better
than configure scripts that tried to figure things out on the fly.
I remember times when source package came with README file saying
edit this and that to configure for your system. Typically one
had to edit Makefile and possibly something like config.h. For
Header files should never have to be manually edited unless the person who
wrote the code didn't know wtf they were doing. #ifdef exists for a reason
and if thats not enough makefiles can always manually concat stuff into a
header.
Post by Waldek Hebisch
me it worked quite well. But those times are gone. Most people
now do not know essential information about system they use, so
are unable to provide sensible values. And modern programs are
Those sorts of people should just install prepackaged binaries, not be building
from source.
Post by Waldek Hebisch
Per platform Makefile-s do not scale when one wants to support
multiple system and multiple configurations (there is exponential
growth of possible combinations). And even of single configuration
See above about ifdef.
Post by Waldek Hebisch
detected quite early. For example, a lot of people try to
compile program without having a C compiler. And when they
See above about installing binaries.
Post by Waldek Hebisch
It is certainly silly when generated configure file is much
bigger than actual program code. This happens frequently
Indeed.
Lawrence D'Oliveiro
2025-03-07 21:26:46 UTC
Permalink
Per platform Makefile-s do not scale when one wants to support multiple
system and multiple configurations (there is exponential growth of
possible combinations). And even of single configuration for supposedly
single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x
represented one Linux flavour. Yet regularly somebody would come and
say: "build fails on my Linux x.y.z". If enough information was
provided new Makefile was added, or possibly some similar Makefile was
modified to cover more cases.
Can you offer more details on the project in question? I ask because
there are things that can be done in GNU Makefiles to deal more
dynamically with environmental differences in some simpler cases,
without resorting to a full-on meta-build system like Autotools or
CMake, and perhaps the maintainers of this project aren’t aware of
that.

Here’s a simple example, building an extension module for Python:

CFLAGS=-g $(shell python3-config --includes) -fPIC -Wall -Wno-switch -Wno-parentheses

gxscript_lexer.so : gxscript_lexer.o
$(CC) $^ $(shell python3-config --ldflags) -shared -o $@

gxscript_lexer.o : gxscript_lexer.c

clean :
rm -f gxscript_lexer.so gxscript_lexer.o
rm -rf __pycache__

.PHONY : clean

Note how it uses the “python3-config” command to figure out the right
flags (including file/directory locations) for compilation and
linking. So it doesn’t have to know that the libraries are in /usr/lib
on one system, and /usr/local/lib on another.
bart
2025-03-07 21:33:40 UTC
Permalink
Post by Lawrence D'Oliveiro
Per platform Makefile-s do not scale when one wants to support multiple
system and multiple configurations (there is exponential growth of
possible combinations). And even of single configuration for supposedly
single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x
represented one Linux flavour. Yet regularly somebody would come and
say: "build fails on my Linux x.y.z". If enough information was
provided new Makefile was added, or possibly some similar Makefile was
modified to cover more cases.
Can you offer more details on the project in question? I ask because
there are things that can be done in GNU Makefiles to deal more
dynamically with environmental differences in some simpler cases,
without resorting to a full-on meta-build system like Autotools or
CMake, and perhaps the maintainers of this project aren’t aware of
that.
CFLAGS=-g $(shell python3-config --includes) -fPIC -Wall -Wno-switch -Wno-parentheses
gxscript_lexer.so : gxscript_lexer.o
gxscript_lexer.o : gxscript_lexer.c
rm -f gxscript_lexer.so gxscript_lexer.o
rm -rf __pycache__
.PHONY : clean
Note how it uses the “python3-config” command to figure out the right
flags (including file/directory locations) for compilation and
linking. So it doesn’t have to know that the libraries are in /usr/lib
on one system, and /usr/local/lib on another.
So how does 'python3-config' know where this stuff is?
Waldek Hebisch
2025-03-10 14:39:27 UTC
Permalink
Post by Lawrence D'Oliveiro
Per platform Makefile-s do not scale when one wants to support multiple
system and multiple configurations (there is exponential growth of
possible combinations). And even of single configuration for supposedly
single system like Linux there are troubles.
In one project there was someting like 20 Makefile.linux_x files where x
represented one Linux flavour. Yet regularly somebody would come and
say: "build fails on my Linux x.y.z". If enough information was
provided new Makefile was added, or possibly some similar Makefile was
modified to cover more cases.
Can you offer more details on the project in question? I ask because
there are things that can be done in GNU Makefiles to deal more
dynamically with environmental differences in some simpler cases,
without resorting to a full-on meta-build system like Autotools or
CMake, and perhaps the maintainers of this project aren’t aware of
that.
I guess that one could do configure-like processing inside a
Makefile generating next stage Makefile. Autoconf offers
ready-to-use functionalty, like a bunch of sanity checks
or check for X libraries. There are several subdirectories
each containing its own Makefile, propagating info via substitution
+ fixed makefile fragments looks esier than Makfile includes
+ conditionals that would be required in make-only solution.

If you look at scale, there is something like 2000 source
file in various languages (including about 50000 wc lines
of C). About 450000 wc lines total, including tests and
documentation (but documentation requires rather involved
build process). About 140 MB generated files.

Some currently suported features:
- using onf of 5 different non-C compilers, each having diferent
extentions for compiled files and needing different way of
creating executable
- matching linking options (shared versus static) and needed
libraries to used compiler
- blacklisting buggy compiler versions
- optionally including/excluding part of functionality
- optinally using machine independent pre-build files
(saves compile time for users building from source)

All this requires some code. It is possible that the work
could be done with less code. However, history suggest
conservative approach. Shortening the whole story, this
is largish formerly propritary program that was released
as open source. First 6 years of open source developement
was mainly spend on build issues. Nontrivial part on
build system, parts on improving portablity of code,
changing tools, etc. Current autoconf based build system
probably represent about 1 man year of developement effort.
During last 15 years build system worked requiring small
maintanence effort. History indicates that changing build
system at least requires some non-trivial effort. And
there is ample opportunity for troubles. So simply,
why spend effort on replacing something that works?

Let me mention due to disagreemnts (including build system,
but not only) project forked. There is or maybe was (in last
few years it made no release) fork which does not use autoconf
and depends on multiple configuration files. It offered
less flexibility and still regularly had build failures
due to changing Linux configurations.
--
Waldek Hebisch
Lawrence D'Oliveiro
2025-03-06 03:16:37 UTC
Permalink
The first step appears to be to run a 35,000-line 'configure' script.
Just a further note, if you’re doing your head in trying to read that --
it’s automatically generated with the m4 macro processor from
configure.ac, which is a much smaller file (less than ¼ the size), and is
the one maintained by humans.
James Kuyper
2025-03-05 00:12:38 UTC
Permalink
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 17:25:27 +0000
...
Post by Richard Heathfield
Post by M***@DastardlyHQ.org
Post by Richard Heathfield
James Kuyper has been posting here for decades, and has helped
Oh well, in that case I bow down in front of his magnificence, he must not
be contradicted!
James would be the first to say that he should be contradicted
when he is mistaken.
I would have been, but I don't see Muttley's messages except when
someone responds to them.

...
Post by Richard Heathfield
And that's the point. The OP needs a local expert - i.e. someone
who has specific experience of building Python with the OP's
specific compiler.
K&R go on (on p25): "If the source program appears in several
files, you may have to say more to compile and load it than if it
all appears in one, but that is an operating system matter, not a
language attribute."
Agreed - that's precisely the point.
Kenny McCormack
2025-03-03 23:42:34 UTC
Permalink
Post by M***@DastardlyHQ.org
On Mon, 3 Mar 2025 11:39:58 -0500
Post by James Kuyper
....
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
Only an arrogant idiot would think that errors on linking object files
generated by a C compiler are not relevant in a C language group.
Indeed. And as you see, there is no shortage of arrogant idiots in
comp.lang.c

'Tis always been thus, and always will be.

BTW, I note that this thread is (still!) posted to 2 other groups, besides
CLC, but the main topic of discussion in the thread (the usual topicality
BS) is, of course, only relevant to CLC.

Funny, that.
--
The book "1984" used to be a cautionary tale;
Now it is a "how-to" manual.
geodandw
2025-03-03 18:29:38 UTC
Permalink
Post by James Kuyper
...
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
responded to by people who are more likely to understand and be
interested in the contents of the message, and can give you better
answers to any questions you have. When you post to the wrong group,
they will be less interested in the message and less capable of giving
good answers to it.
However, if you're not interested in getting good answers to your
questions, and it doesn't bother you that your messages are going to
people not interested in the topic of your message, by all means post to
any group you choose. This isn't a moderated group - no one can stop you
from posting here.
Even if it is topicality, whey people rude and insulting to others in
this group?
James Kuyper
2025-03-03 21:52:42 UTC
Permalink
Post by geodandw
Post by James Kuyper
...
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Because what you call intolerance, we call topicality. When you post a
message to a group where it is on-topic, the message gets seen and
responded to by people who are more likely to understand and be
interested in the contents of the message, and can give you better
answers to any questions you have. When you post to the wrong group,
they will be less interested in the message and less capable of giving
good answers to it.
However, if you're not interested in getting good answers to your
questions, and it doesn't bother you that your messages are going to
people not interested in the topic of your message, by all means post to
any group you choose. This isn't a moderated group - no one can stop you
from posting here.
Even if it is topicality, whey people rude and insulting to others in
this group?
I don't know. I've got most of the rudest people killfiled, so I'm not
exposed to them very much except when someone responds to them. I've
little insight into why they behave the way that they do.

However, the context of your comment suggests that you may consider
something that I said to be rude or insulting. Is that correct? If so,
could you identify what that was? I can assure you that nothing I wrote
in this thread was meant to be rude or insulting.

I'm afraid that I can't make a more general statement to that effect - I
believe that rudeness is sometimes an appropriate way to inform someone
that they've stepped over the line into unacceptable behavior. "You cut
into the line in front of me!" might be considered rude, but it is also
an appropriate response, if true. Similarly, accusing someone of lying
might be considered insulting, but if they were indeed lying, the insult
is earned.
Richard Heathfield
2025-03-03 17:19:39 UTC
Permalink
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as
it is a question
regarding a linker, interacting
with the results of various options given to a specific
compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language.
Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs
wouldn't be
much use, either. That doesn't make a malfunctioning computer
monitor a
C problem. And it doesn't make a linkage problems a C problem
either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The
subject line
and the text of the error messages indicate that it's a
Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to
comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of
earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You
might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
  That sounds like a C issue to me.
If it were a C problem, then the C source code that produced
the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this
group topical?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
geodandw
2025-03-03 18:33:44 UTC
Permalink
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
  That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this group
topical?
A. Because the problem is apparently using the right options on the
compiler, which seems like a C question to me.
B.Because some people in this group are arrogant. rude, and
insulting..If the shoe fits, wear it.
Richard Heathfield
2025-03-03 19:15:48 UTC
Permalink
<snip>
Post by geodandw
Post by Richard Heathfield
Post by geodandw
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this
group topical?
A. Because
[...reason...]

Clearly you have no objection to intolerance as long as it's you
doing it.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
geodandw
2025-03-03 23:51:52 UTC
Permalink
Post by Richard Heathfield
<snip>
Post by geodandw
Post by geodandw
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this group
topical?
A. Because
[...reason...]
Clearly you have no objection to intolerance as long as it's you doing it.
Disliking intolerance is not intolerance.
Kaz Kylheku
2025-03-04 00:49:30 UTC
Permalink
Post by geodandw
Post by Richard Heathfield
Clearly you have no objection to intolerance as long as it's you doing it.
Disliking intolerance is not intolerance.
Disruption of a forum topic is not a protected activity, and
the perpetrators are not members of a protected class.

Intolerance of off-topic disruptors isn't the same as intolerance
of an ethnicity or race, etc.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Richard Heathfield
2025-03-04 02:29:44 UTC
Permalink
Post by geodandw
Post by Richard Heathfield
<snip>
Post by geodandw
Post by Richard Heathfield
Post by geodandw
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this
group topical?
A. Because
[...reason...]
Clearly you have no objection to intolerance as long as it's
you doing it.
Disliking intolerance is not intolerance.
What you are failing to tolerate is the wish to have a topical
group, and intolerance is exactly the right word for your failure
to respect the longstanding topicality requirements of this group.

If you had earned the right to your intolerance on the matter by
establishing over many years a longstanding track record of
helping people with good natured and topical C advice, maybe I'd
be prepared to regard your opinion with more respect, but I find
it hard to respect someone who has so little sense of the history
and experience of this group.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
David Brown
2025-03-04 08:12:38 UTC
Permalink
Post by geodandw
Post by geodandw
Post by James Kuyper
  That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this group
topical?
A. Because the problem is apparently using the right options on the
compiler, which seems like a C question to me.
I don't know what your experience with C is - if you have posted
anything in c.l.c. that indicates that, it must have been too long ago
for me to remember. But a number of people with decades long experience
of not only working with C, but helping people in c.l.c. with their C
problems, have made it clear that this is /not/ a C question. They also
did their best to help the OP - giving what help they could despite this
being the wrong place and the question being off-topic, and they did
their best to redirect the OP to places where he might get more useful help.
Post by geodandw
B.Because some people in this group are arrogant. rude, and
insulting..If the shoe fits, wear it.
Originally, people /politely/ pointed out that the post was off-topic,
and the OP was unlikely to get good help here. Indeed, I don't think
anyone has been other than polite to the OP.

But there have been two people in this thread who have perhaps been
rude, arrogant and insulting - insisting that /they/ know better than
the regulars about what is topical and not topical for the group. Those
posters have not in any way been helpful, and are just a waste of
bandwidth for everyone else.

I don't know what you think you are trying to achieve here. Do you
think that your complaints will somehow magically make the OP's problem
about the C programming language, rather than the build process for a
particular and specific complex piece of software? Do you think that by
posting repeatedly, someone here will suddenly realise they know
something that could help the OP? Do you think you will change the
group topicality?

All you have achieved is annoying some people, and ensuring that the
thread can't develop topically.

If you want to understand what is topical or not for this group,
consider if a question could conceivably by used as an example or an
exercise in a published book about learning or using the C programming
language. Then it is probably on-topic. If you'd only find it in a
book called "C programming for Windows", or "Systems programming in
Unix", or "C development with gcc", then it is likely to be too
specific. The OP's question is far too niche for any kind of book at
all - he needs to look at build instructions for Python to understand
what is going on.
Richard Heathfield
2025-03-04 11:33:22 UTC
Permalink
On 04/03/2025 08:12, David Brown wrote:

<snip>
Post by David Brown
Originally, people /politely/ pointed out that the post was
off-topic, and the OP was unlikely to get good help here.
Indeed, I don't think anyone has been other than polite to the OP.
But there have been two people in this thread who have perhaps
been rude, arrogant and insulting - insisting that /they/ know
better than the regulars about what is topical and not topical
for the group.  Those posters have not in any way been helpful,
What did you expect from them? A demonstration of competence?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DinkyHQ.org
2025-03-04 12:00:22 UTC
Permalink
On Tue, 4 Mar 2025 11:33:22 +0000
Post by Richard Heathfield
<snip>
Post by David Brown
Originally, people /politely/ pointed out that the post was
off-topic, and the OP was unlikely to get good help here.
Indeed, I don't think anyone has been other than polite to the OP.
But there have been two people in this thread who have perhaps
been rude, arrogant and insulting - insisting that /they/ know
better than the regulars about what is topical and not topical
for the group.  Those posters have not in any way been helpful,
What did you expect from them? A demonstration of competence?
Ah, the arrogance just keeps on giving. Define "regulars". I tend to lurk
on a lot of groups and occasionally post and I've been a "regular" on usenet as
a whole since 1992 so I'm pretty used to self important types like you and
Brown.
Michael S
2025-03-04 13:31:01 UTC
Permalink
On Tue, 4 Mar 2025 09:12:38 +0100
Post by David Brown
Originally, people /politely/ pointed out that the post was
off-topic, and the OP was unlikely to get good help here. Indeed, I
don't think anyone has been other than polite to the OP.
But there have been two people in this thread who have perhaps been
rude, arrogant and insulting - insisting that /they/ know better than
the regulars about what is topical and not topical for the group.
Those posters have not in any way been helpful, and are just a waste
of bandwidth for everyone else.
OP did to himself by cross-posting to comp.lang.c++.
comp.lang.c++ group has some good virtues, but civilized tone of
discussions is not among them.
David Brown
2025-03-03 17:28:20 UTC
Permalink
Post by geodandw
Why is this group so intolerant?
These groups (comp.lang.c and comp.lang.c++ - it's a long time since I
looked at comp.lang.python, but I expect things are similar there) are
very tolerant of most posters, but there are few people who seem to
delight in annoying people and spreading their own confusion.

The posts here are mostly trying to give the OP what little help they
can, and then direct him towards better sources of information - or they
are trolls by an anonymous coward who regularly changes his nom de
guerre because he is killfiled by so many people.
M***@DastardlyHQ.org
2025-03-04 08:33:57 UTC
Permalink
On Mon, 3 Mar 2025 18:28:20 +0100
Post by David Brown
Post by geodandw
Why is this group so intolerant?
These groups (comp.lang.c and comp.lang.c++ - it's a long time since I
looked at comp.lang.python, but I expect things are similar there) are
very tolerant of most posters, but there are few people who seem to
delight in annoying people and spreading their own confusion.
The posts here are mostly trying to give the OP what little help they
can, and then direct him towards better sources of information - or they
are trolls by an anonymous coward who regularly changes his nom de
guerre because he is killfiled by so many people.
"Troll" here being the snowflake definition of the word - ie "someone I
disagree with but am unable to counter his arguments to any great extent"
Kaz Kylheku
2025-03-04 18:06:09 UTC
Permalink
At the risk of sounding intolerant, I suggest that the discussion not be
crossposted comp.lang.python.
You did not do it in the best way. The way this suggestion is performed
is like this, using a built-in Usenet mechanism:

1. Keep the Newsgroups: line as-is.
1. a) Unless it contains a ridiculous number of newsgroups,
in which case consider killfiling the thread rather
than adding to it, or else trim out obviously
ridiculous newsgroup choices to get it down to three or four.
2. Add a header called "Followup-To:" to your posting which lists
the newsgroups where you would like replies to article to be
directed.
3. Mention in the article of the body that you're doing this,
for example:

"I think this discussion doesn't belong in comp.lang.python, so
I'm setting Followup-To accordingly to omit that group."

Followup-To is exactly that: a suggestion. Users agents can (and do)
prompt the user whether they want to honor Followup-To or ignore it.

Followup-To is much better than just removing newsgroups from the
Newsgroups line, because doing so fragments the thread without warning.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @***@mstdn.ca
Stuart Redmann
2025-03-06 06:35:38 UTC
Permalink
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Members of this group are quite likely old (only old people remember Usenet
it seems), maybe even retired. Old people are often a bit set in their way
(correcting your grammar all the time, trying to force their political
views on you, etc. etc.)

Also, programming tends to attract people that can handle highly formalized
thinking, and thus also people who have OCD to a higher or lower degree.
Think of them as if they were Sheldon. They probably don‘t see that their
musings about topicality of your question won’t help you at all, they have
simply hijacked your thread to discuss about whether linker problems are
topical in this newsgroup (they could have done this in a separate thread).

I have to admit that this thread turned out to be the most interesting
since a long time, although not for OP. It’s like the ramblings of an old
man that you asked about help with your spark plugs and he ends up talking
about his experiences during WWII. Don‘t take offense, nod politely, and
find someone who’s actually going to help you ;-)

IIRC, there are two different ways of compiling code, position dependent or
position independent (PIC). Apparently you cannot mix these two kinds of
code into a single executable. So if you are using a library that has been
compiled with PIC turned on, you’ll have to compile your code the same way.
There should be a command line parameter/IDE setting to do so, depending on
your toolchain.

Kind regards
Stuart
Richard Heathfield
2025-03-06 07:32:33 UTC
Permalink
Post by Stuart Redmann
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Members of this group are quite likely old (only old people remember Usenet
it seems), maybe even retired. Old people are often a bit set in their way
(correcting your grammar all the time, trying to force their political
views on you, etc. etc.)
Also, programming tends to attract people that can handle highly formalized
thinking, and thus also people who have OCD to a higher or lower degree.
Think of them as if they were Sheldon. They probably don‘t see that their
musings about topicality of your question won’t help you at all, they have
simply hijacked your thread to discuss about whether linker problems are
topical in this newsgroup (they could have done this in a separate thread).
I have to admit that this thread turned out to be the most interesting
since a long time, although not for OP. It’s like the ramblings of an old
man that you asked about help with your spark plugs and he ends up talking
about his experiences during WWII. Don‘t take offense, nod politely, and
find someone who’s actually going to help you ;-)
Firstly, you're talking to the wrong guy. The OP - the person who
actually needs the help - is long gone. Muttley is just the
juvenile delinquent from round the corner who likes to drop
litter in the old folks' yards.

But you're right anyway. The OP does indeed need to "find someone
who’s actually going to help you", which is why he needs to ask
his question in the kind of group where building Python from
source is the kind of question that attracts attention from
experts in that area. So, instead of dead-heading the roses in
the old folks' gardens, the very best help that Muttley could
have offered the OP is to direct him to a group that's a better
fit for the question. Or... hey... if he's so set on turning up
his noise to annoy everyone *anyway*, why not just use the air
time to answer the question himself?

Oh, yeah, we know that one, don't we? He can't, because he
clearly doesn't know the answer, 'cos what kind of jerk who could
walk the OP through his problem would have wasted so much time
pissing in flower-beds instead?
Post by Stuart Redmann
IIRC, there are two different ways of compiling code, position dependent or
position independent (PIC). Apparently you cannot mix these two kinds of
code into a single executable. So if you are using a library that has been
compiled with PIC turned on, you’ll have to compile your code the same way.
There should be a command line parameter/IDE setting to do so, depending on
your toolchain.
And IYRI? Presumably in that circumstance you'd hope that a local
expert would pick up on your error and offer a better steer to
the OP. Preferably one who knows the ins and outs of the relevant
toolchain, which is of course independent of the toolchain being
used (linkers link object code, not source code, so they don't
give a damn what source language was used).

So whaddya know? Turns out the old farts were right after all.
How about that?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
M***@DastardlyHQ.org
2025-03-06 08:39:56 UTC
Permalink
On Thu, 6 Mar 2025 07:32:33 +0000
Post by Richard Heathfield
Post by Stuart Redmann
I have to admit that this thread turned out to be the most interesting
since a long time, although not for OP. It’s like the ramblings of an old
man that you asked about help with your spark plugs and he ends up talking
about his experiences during WWII. Don‘t take offense, nod politely, and
find someone who’s actually going to help you ;-)
Firstly, you're talking to the wrong guy. The OP - the person who
actually needs the help - is long gone. Muttley is just the
juvenile delinquent from round the corner who likes to drop
litter in the old folks' yards.
First time I've been called a juvenile delinquent in probably 40 years
but i'll take it as a complement.

But congratulations on so nicely proving his point for him.

Oh, wait, you won't read this because you supposedly killfiled me since like
a lot of people of your type - if you can't win an argument just ignore the
person who defeated you. Now I wonder which one of us has the more juvenile
behaviour.
Post by Richard Heathfield
the old folks' gardens, the very best help that Muttley could
have offered the OP is to direct him to a group that's a better
fit for the question. Or... hey... if he's so set on turning up
his noise to annoy everyone *anyway*, why not just use the air
time to answer the question himself?
I didn't respond to the OPs question. Only the idiots like you telling him
this wasn't a suitable group for it. Do try to keep up with the thread
grandad.

Congratulations on so comprehensively proving his point.

Don't worry, I'll get off your lawn now! LOL :)
Chris M. Thomasson
2025-03-06 20:40:48 UTC
Permalink
Post by Stuart Redmann
Post by geodandw
Post by James Kuyper
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Without computers, keyboards and monitors most C programs wouldn't be
much use, either. That doesn't make a malfunctioning computer monitor a
C problem. And it doesn't make a linkage problems a C problem either.
Post by M***@DastardlyHQ.org
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C.
The indentations of the first message cross-posted to comp.lang.c and
comp.lang.c++ suggest that it was the latest in a series of earlier
messages posted somewhere else (comp.lang.python?). Those earlier
messages might have contained additional information. If that
information was relevant, it should have been included when the message
was first cross-posted to comp.lang.c or comp.lang.c++. You might be
right about it being "Python source code ... written in C", but nothing
in the messages that were posted here makes that obvious.
That sounds like a C issue to me.
If it were a C problem, then the C source code that produced the problem
should have been shown. It's hard to debug code that you can't see.
Why is this group so intolerant?
Members of this group are quite likely old (only old people remember Usenet
it seems), maybe even retired.
I am 47, kind of old?
Post by Stuart Redmann
Old people are often a bit set in their way
(correcting your grammar all the time, trying to force their political
views on you, etc. etc.)
;^)
Post by Stuart Redmann
Also, programming tends to attract people that can handle highly formalized
thinking, and thus also people who have OCD to a higher or lower degree.
Think of them as if they were Sheldon. They probably don‘t see that their
musings about topicality of your question won’t help you at all, they have
simply hijacked your thread to discuss about whether linker problems are
topical in this newsgroup (they could have done this in a separate thread).
I have to admit that this thread turned out to be the most interesting
since a long time, although not for OP. It’s like the ramblings of an old
man that you asked about help with your spark plugs and he ends up talking
about his experiences during WWII. Don‘t take offense, nod politely, and
find someone who’s actually going to help you ;-)
IIRC, there are two different ways of compiling code, position dependent or
position independent (PIC). Apparently you cannot mix these two kinds of
code into a single executable. So if you are using a library that has been
compiled with PIC turned on, you’ll have to compile your code the same way.
There should be a command line parameter/IDE setting to do so, depending on
your toolchain.
James Kuyper
2025-03-07 18:17:28 UTC
Permalink
On 3/6/25 01:35, Stuart Redmann wrote:
...
Post by Stuart Redmann
IIRC, there are two different ways of compiling code, position dependent or
position independent (PIC). Apparently you cannot mix these two kinds of
code into a single executable. So if you are using a library that has been
compiled with PIC turned on, you’ll have to compile your code the same way.
Trick question: what changes do you need to make to your C source code
to determine whether position dependent or position independent code is
generated?
Post by Stuart Redmann
There should be a command line parameter/IDE setting to do so, depending on
your toolchain
So, there's no general answer, there's a different answer for different
toolchains. And so the best place to get a toolchain-specific answer is
in a forum devoted to the toolchain you use.
The Doctor
2025-03-03 16:12:16 UTC
Permalink
Post by M***@DastardlyHQ.org
On Sun, 2 Mar 2025 12:30:53 -0500
Post by James Kuyper
Post by M***@dastardlyhq.com
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question
regarding a linker, interacting
with the results of various options given to a specific compiler.
Is there a comp.lang.c.linker group?
comp.lang.c is about using the C programming language. Linkers are
independent of the programming language, and can be used to link
Without compilers and linkers a C program would just be a load of text.
Post by James Kuyper
together programs written in many different languages. The subject line
and the text of the error messages indicate that it's a Python program,
so why would a group devoted to C be in any way appropriate?
If you'd taken 2 seconds to look at it you'd realise the issue was building
the Python source code which is written in C. That sounds like a C issue to me.
I am now trying without the static library.
--
Member - Liberal International This is ***@nk.ca Ici ***@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
Ontario vote for the Liberals - The best Anti-Trump option!
Left Right
2025-03-02 22:26:07 UTC
Permalink
I think Python compiles with fPIC by default. Something else had
happened to the OPs checkout that caused these errors. OP needs to
better describe what they were doing to properly understand the
problem.

On Sun, Mar 2, 2025 at 10:10 PM Lew Pitcher via Python-list
Post by Lew Pitcher
First off, this isn't really on-topic for comp.lang.c, as it is a question regarding a linker, interacting
with the results of various options given to a specific compiler.
However...
Post by The Doctor
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
The error message tells you exactly how to fix the problem: recompile the module using the
-fPIC
option to the compiler. -fPIC tells your compiler to generate a specific type of position-independant
code, which your linker (apparently) requires for a specific type of relocation.
[snip]
HTH
--
Lew Pitcher
"In Skills We Trust"
--
https://mail.python.org/mailman/listinfo/python-list
Waldek Hebisch
2025-03-02 17:54:35 UTC
Permalink
Post by The Doctor
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.
--
Waldek Hebisch
Richard Heathfield
2025-03-02 19:15:48 UTC
Permalink
Post by Waldek Hebisch
Post by The Doctor
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.
I have written hundreds of thousands of lines of real-world code
in standard C, all of which would be topical here. The real world
is bigger than you think.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
James Kuyper
2025-03-02 18:38:50 UTC
Permalink
Post by Waldek Hebisch
Post by The Doctor
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 Doctor
2025-03-03 00:42:23 UTC
Permalink
Post by The Doctor
Post by Waldek Hebisch
Post by The Doctor
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
Post by Waldek Hebisch
Post by The Doctor
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
Post by Waldek Hebisch
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?.
Note the C error!
--
Member - Liberal International This is ***@nk.ca Ici ***@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
Ontario vote for the Liberals - The best Anti-Trump option!
The Doctor
2025-03-03 00:46:01 UTC
Permalink
Post by The Doctor
Post by The Doctor
Post by Waldek Hebisch
Post by The Doctor
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
Post by Waldek Hebisch
Post by The Doctor
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
Post by Waldek Hebisch
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?.
Note the C error!
I did add the -fPIC . will try the -no-pie .
Post by The Doctor
--
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
Ontario vote for the Liberals - The best Anti-Trump option!
--
Member - Liberal International This is ***@nk.ca Ici ***@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ;
Ontario vote for the Liberals - The best Anti-Trump option!
James Kuyper
2025-03-03 03:24:22 UTC
Permalink
Post by The Doctor
Post by The Doctor
Post by Waldek Hebisch
Post by The Doctor
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol
'_PyRuntime'; recompile with -fPIC
Post by Waldek Hebisch
Post by The Doctor
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
Post by Waldek Hebisch
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?.
Note the C error!
The message indicates that PyRuntime is referenced inside
Python/thread_pthread.h, which is likely to have been #included in some
C code. However, the error message indicates that the problem is not
about the C code, but about linkage. The C code is just one of the two
things that need to be linked together. The solution is a linker option,
not a change anything in the C code.
Waldek Hebisch
2025-03-03 17:20:33 UTC
Permalink
Post by James Kuyper
Post by Waldek Hebisch
Post by The Doctor
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
Richard Heathfield
2025-03-03 17:28:00 UTC
Permalink
<snip>
Post by Waldek Hebisch
Post by James Kuyper
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.
So you agree that C /interpreters/ are off-topic here.

It's a start.

<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
James Kuyper
2025-03-03 17:57:04 UTC
Permalink
On 3/3/25 12:20, Waldek Hebisch wrote:
...
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
- linking is considerd part of C implementation
- '-fPIC' is option for compiler proper
- '-no-pie' is handled by the compiler driver
Here is the entirety of what the C standard says about translation phase
8, where programs are linked together:

"All external object and function references are resolved. Library
components are linked to satisfy external references to functions and
objects not defined in the current translation. All such translator
output is collected into a program image which contains information
needed for execution in its execution environment." (5.1.2.2p8)

Please tell me what that says that is relevant to the solution of this
problem? The PIC in that option refers to "Position Independent Code", a
topic about which the C standard says nothing. Whether or not that
option is needed or even helpful is outside the scope of C.
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.
More directly to the point, programmers who aren't C programmers also
want to do it, and how it is done has nothing to do with C, and a lot to
do with the linker. The linker can be language-neutral, and in my
experience usually is, at least on the Unix-like platforms that I have
the most experience on (though I have heard of some language-specific
linkers).
Scott Lurndal
2025-03-03 18:02:32 UTC
Permalink
Post by Waldek Hebisch
Post by James Kuyper
Post by Waldek Hebisch
Post by The Doctor
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.
So why are you cross posting to comp.lang.c++ and comp.lang.python?
bart
2025-03-03 19:37:02 UTC
Permalink
Post by Waldek Hebisch
Post by James Kuyper
Post by Waldek Hebisch
Post by The Doctor
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
- linking is considerd part of C implementation
C requires independent compilation. It doesn't say how that should be done.
Post by Waldek Hebisch
- '-fPIC' is option for compiler proper
- '-no-pie' is handled by the compiler driver
Those are compiler- and platform-specific options, nothing to do with
the language.

My two C compilers don't use a linker.
Post by Waldek Hebisch
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.
There are a thousand C compilers; I can't imagine that their options and
various capabilities are all on topic.

gcc is sometimes given a free pass because it is so widely used, but the
options used with it are more general (eg. -O3 or -s).
Post by Waldek Hebisch
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.
That's even more off-topic. Build systems use things like CMake and Make
which have their own syntax, and which are designed to work with
multiple languages.
Post by Waldek Hebisch
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.
Fortran itself is rather niche; C isn't.

I suggested that Reddit or Stackoverflow could be used, as they're less
fussed. There would also be a lot more people who could help.

On Reddit, the main C forum has 186K members, and the Fortran one under
8K. However, the Python subreddit has 1.3M members; that might be worth
trying too.
Lawrence D'Oliveiro
2025-03-04 05:46:49 UTC
Permalink
Post by The Doctor
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
[etc]

So, at a wild guess, it looks like the symbol “_PyRuntime” is defined
in one module (pylifecycle.o) which is compiled non-PIC, and is being
referenced in another module (thread.o) which was compiled as PIC. Or
maybe it’s the other way round.

How you managed to end up with inconsistent flags for different parts
of your build, I don’t know. But that’s what needs to be fixed.
Loading...