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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Compilation failed unexpectedly.Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
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.
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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?
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
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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?
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c.
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol >'_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive >/usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest >reasonable interpretation, so why should it be discussed here?.
In article <vq2j3n$v2fk$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol >>'_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive >>/usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C. >>You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind >>your of that. It's a misunderstanding of those redirections to conclude >>that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest >>reasonable interpretation, so why should it be discussed here?.
Note the C error!
----
Member - Liberal International This is doctor@nk.ca Ici doctor@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!
In article <vq2j3n$v2fk$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:'_PyRuntime'; recompile with -fPIC
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol
/usr/local/lib/libpython3.13.adefined 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
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!
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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?
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
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.
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
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.
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.
On Mon, 3 Mar 2025 08:31:16 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
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.
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.
an issue for a specific compiler group.
So which group would that be then?
On Mon, 3 Mar 2025 08:31:16 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
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.
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.
an issue for a specific compiler group.
So which group would that be then?
On 03/03/2025 10:44, Muttley@DastardlyHQ.org wrote:
On Mon, 3 Mar 2025 08:31:16 +0000
Really? So if a compiler gives an error thats not a C problem? Go ask a
group for the specific compiler?
The errors reported by the OP were like this:
ld: error: relocation R_X86_64_32 cannot be used against symbol >'_PyRuntime'; recompile with -fPIC
'ld' is a program that can be used to link programs in any language.
The problem appears to be do with generating position independent code
since these days linkers like to generate programs that can loaded at an >arbitrary address in high memory.
I can't see anything to do with C here, other than the source in
question may have been written in C.
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.
On usenet? That is pretty much dead.
On 03/03/2025 10:44, Muttley@DastardlyHQ.org wrote:
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?
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.
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
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.
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
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.
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
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.
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.
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
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.
On 3/3/25 10:22, James Kuyper wrote:
If it were a C problem, then the C source code that produced the problemWhy is this group so intolerant?
should have been shown. It's hard to debug code that you can't see.
On 3/3/25 10:22, James Kuyper wrote:...
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
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.
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138)
thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest reasonable interpretation, so why should it be discussed here?.
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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.
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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.
In comp.lang.c James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
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.
Why is this group so intolerant?
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.
In comp.lang.c James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
The question is about C implementation.
On 3/3/25 11:24, geodandw wrote:Even if it is topicality, whey people rude and insulting to others in
On 3/3/25 10:22, James Kuyper wrote:...
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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.
On 03/03/2025 16:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500Without computers, keyboards and monitors most C programs wouldn't be
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a >>>>>>> questionIs there a comp.lang.c.linker group?
regarding a linker, interacting
with the results of various options given to a specific compiler. >>>>>>
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. >>>
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.
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 are you so intolerant of other people's wish to keep this group
topical?
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
Why is this group so intolerant?
Why are you so intolerant of other people's wish to keep this
group topical?
A. Because
In comp.lang.c James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 3/2/25 12:54, Waldek Hebisch wrote:
In comp.lang.c The Doctor <doctor@doctor.nl2k.ab.ca> wrote:
How do I compensate for
ld: error: relocation R_X86_64_32 cannot be used against symbol '_PyRuntime'; recompile with -fPIC
defined in /usr/local/lib/libpython3.13.a(pylifecycle.o)
referenced by thread_pthread.h:138 (Python/thread_pthread.h:138) >>>>>>> thread.o:(PyThread_init_thread) in archive /usr/local/lib/libpython3.13.a
This is real world question and as such is considered off-topic
in comp.lang.c. However, you could try '-no-pie' to the compiler.
Real world questions about the C programming language are entirely
on-topic here. Note, however, that many questions posted here are not
about C itself, but about the quirks of particular implementations of C.
You can get better answers to such questions by asking in forums
specific to the relevant implementation, and helpful people will remind
your of that. It's a misunderstanding of those redirections to conclude
that c.l.c is not for real world questions.
However Python is NOT an implementation of C, not even by the loosest
reasonable interpretation, so why should it be discussed here?.
The question is about C implementation. Namely, the bible for
this group, that is C standard requires C implementation to
produce executables. And making executable from C sources
it at core of the OP question. Fact that compiling this source
is supposed to produce Python interpreter or maybe some
supporting shared library is irrelevant here.
One could call the problem "Linux problem". Namely, many
(maybe all) Linux distribution modify(ed) gcc so that creating
position independent executables is the default and to
prevent this one need '-no-pie' at final stage. And to
generate position independent executable all code has to
be compiled as position independent code which needs '-fPIC'
option. Similarly, if OP is trying to create shared
library, then on Linux all code inluded in the shared
librayr must be compiled as position independent code,
that is using '-fPIC'.
Dismissing this as linker problem misses important
points:
- linking is considerd part of C implementation
- '-fPIC' is option for compiler proper
- '-no-pie' is handled by the compiler driver
And frankly, making executables or shared library from
C code is real world thing that C programmer want to do
and non-programmers would not do.
OP uses some build system and fixing his problem presumably
needs changes to build system. And reasonably build system
may be cosidered of topic here.
However, fact that compilation
proper and final linking must use consitent options is
real world C problem. I appreciate that many years ago
comp.lang.c regulars decided that they do not want to answer
such real world question. However, do you want to tell OP
"pretend that your main program is in Fortran and ask your
question in comp.lang.fortran"? FYI, similar questions were
asked and answered in comp.lang.fortran without questioning
topicality. So clearly, the only thing which makes such
question of topic here is past deliberate decision to exclude
them.
On 3/3/25 11:39, James Kuyper wrote:
On 3/3/25 11:24, geodandw wrote:Even if it is topicality, whey people rude and insulting to others in
On 3/3/25 10:22, James Kuyper wrote:...
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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.
this group?
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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.
On 03/03/2025 18:33, geodandw wrote:
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
<snip>
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.
On 3/3/25 14:15, Richard Heathfield wrote:
Clearly you have no objection to intolerance as long as it's you doing it. >>Disliking intolerance is not intolerance.
On 3/3/25 14:15, Richard Heathfield wrote:
On 03/03/2025 18:33, geodandw wrote:Disliking intolerance is not intolerance.
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
<snip>
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.
On 3/3/25 12:19, Richard Heathfield wrote:
On 03/03/2025 16:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:
That sounds like a C issue to me.Why is this group so intolerant?
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 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.
On 03/03/2025 17:56, Muttley@DastardlyHQ.org wrote:
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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
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.
On 03/03/2025 16:56, Muttley@DastardlyHQ.org wrote:
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
Why is this group so intolerant?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.
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/.
On 03/03/2025 17:24, geodandw wrote:
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.
On Mon, 3 Mar 2025 17:25:27 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 03/03/2025 16:56, Muttley@DastardlyHQ.org wrote:
On Mon, 3 Mar 2025 11:39:58 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On 3/3/25 11:24, geodandw wrote:
On 3/3/25 10:22, James Kuyper wrote:....
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:
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!
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.
On Mon, 3 Mar 2025 18:28:20 +0100
David Brown <david.brown@hesbynett.no> wibbled:
On 03/03/2025 17:24, geodandw wrote:
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"
On 04/03/2025 08:32, Muttley@DastardlyHQ.org wrote:
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.
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
On Tue, 4 Mar 2025 08:56:57 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 04/03/2025 08:32, Muttley@DastardlyHQ.org wrote:
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?
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":
*yawn*
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.
On 04/03/2025 09:23, Muttley@DastardlyHQ.org wrote:
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.
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.
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.
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 04/03/2025 09:23, Muttley@DastardlyHQ.org wrote:
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?
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.
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...
that compilation no longer depends on the system you are using
and has now become a language attribute? Can you hear the
chuckles yet?
Wtf has the language standard got to do with anything?
On 04/03/2025 10:03, Muttley@DastardlyHQ.org wrote:
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 04/03/2025 09:23, Muttley@DastardlyHQ.org wrote:
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.
get someone else to compile your code for you?
I tell the compiler to do it. Don't you?
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).
Is K&R outdated? Hmm, let me think about that for a nanosecond...
So it *is* your claim that...
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?
Wtf has the language standard got to do with anything?
Yep; time to plonk.
Bye-bye.
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,
On 04/03/2025 08:12, David Brown wrote:
<snip>
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?
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.
Compilation is a fundamental part of developing in C.
On Tue, 4 Mar 2025 09:57:16 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
On 04/03/2025 09:23, Muttley@DastardlyHQ.org wrote:
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?
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.
At the risk of sounding intolerant, I suggest that the discussion not be crossposted comp.lang.python.
On 04/03/2025 08:32, Muttley@DastardlyHQ.org wrote:...
On Mon, 3 Mar 2025 17:25:27 +0000
Richard Heathfield <rjh@cpax.org.uk> wibbled:
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.
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."
On 2025-03-04, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
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.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2025-03-04, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
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."
Thank you for the information - I had not been aware of this possibility.
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.
Yes, my UA, Gnus, did indeed prompt me.
Followup-To is much better than just removing newsgroups from the
Newsgroups line, because doing so fragments the thread without
warning.
But will there be any difference for the newsgroup which has been
removed? If the follow-up suggestion is adhered to, the thread will
just end in the same way it would if the group had been removed from the
list of newsgroups, won't it?
But will there be any difference for the newsgroup which has been
removed? If the follow-up suggestion is adhered to, the thread will
just end in the same way it would if the group had been removed from the
list of newsgroups, won't it?
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
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.
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.
geodandw <geodandw@gmail.com> wrote:
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500Without computers, keyboards and monitors most C programs wouldn't be
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a questionIs there a comp.lang.c.linker group?
regarding a linker, interacting
with the results of various options given to a specific compiler. >>>>>>
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. >>>
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.
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.
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.
On 06/03/2025 06:35, Stuart Redmann wrote:
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.
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?
geodandw <geodandw@gmail.com> wrote:
On 3/3/25 10:22, James Kuyper wrote:
On 03/03/2025 08:13, Muttley@DastardlyHQ.org wrote:Why is this group so intolerant?
On Sun, 2 Mar 2025 12:30:53 -0500Without computers, keyboards and monitors most C programs wouldn't be
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:
On Sun, 02 Mar 2025 16:58:20 +0000, Muttley wrote:
On Sun, 2 Mar 2025 15:54:19 -0000 (UTC)
Lew Pitcher <lew.pitcher@digitalfreehold.ca> gabbled:
First off, this isn't really on-topic for comp.lang.c, as it is a questionIs there a comp.lang.c.linker group?
regarding a linker, interacting
with the results of various options given to a specific compiler. >>>>>>
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. >>>
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.
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.
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.
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
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,029 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 180:52:37 |
| Calls: | 13,336 |
| Calls today: | 3 |
| Files: | 186,574 |
| D/L today: |
5,114 files (1,408M bytes) |
| Messages: | 3,356,559 |