Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: bart Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.python Subject: Re: Python recompile Date: Mon, 3 Mar 2025 19:37:02 +0000 Organization: A noiseless patient Spider Lines: 100 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 03 Mar 2025 20:37:01 +0100 (CET) Injection-Info: dont-email.me; posting-host="71ccf53cfd1901b67d85c65a66d0edd4"; logging-data="1539163"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19LDalrfBoH1ocewhZ9jcMa" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:hPlYHmkEdM49Zepmcy43H9XvfyI= In-Reply-To: Content-Language: en-GB Xref: csiph.com comp.lang.c:390718 comp.lang.c++:121847 comp.lang.python:197320 On 03/03/2025 17:20, Waldek Hebisch wrote: > In comp.lang.c James Kuyper wrote: >> On 3/2/25 12:54, Waldek Hebisch wrote: >>> In comp.lang.c The Doctor 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 C requires independent compilation. It doesn't say how that should be done. > - '-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. > 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). > 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. > 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.