Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Muttley@DastardlyHQ.org Newsgroups: comp.lang.c Subject: Re: Python recompile Date: Mon, 17 Mar 2025 16:32:32 -0000 (UTC) Organization: A noiseless patient Spider Lines: 41 Message-ID: References: <871pv861ht.fsf@nosuchdomain.example.com> <20250308192940.00001351@yahoo.com> <874izvjs4m.fsf@nosuchdomain.example.com> <87senfi7ii.fsf@nosuchdomain.example.com> Injection-Date: Mon, 17 Mar 2025 17:32:32 +0100 (CET) Injection-Info: dont-email.me; posting-host="2ab1be3dd2111373d3063d43a619f6ca"; logging-data="556483"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19bbKB5us/bwT2PhYkfDiRD" Cancel-Lock: sha1:lKSxKuvX8tlAs57gQlgoSAuZ3TA= Bytes: 3476 On Mon, 17 Mar 2025 14:25:46 +0000 bart wibbled: >On 17/03/2025 12:07, Muttley@DastardlyHQ.org wrote: >> Anything C could do so long as you don't include all the standard C libraries > >> in "anything". > >Another mysterious remark. You seem to consider it your job to put down >anything I do or say! > >So, what do the standard C libraries have to do with anything here? They're generally the interface to the OS on *nix. No idea about windows. >where mm is a compiler. That itself was in the context of build tools on >Linux which usually involve makefiles, shell scripts and other >OS-specific junk, which was touted to be far superior to the Windows >experience. So presumably your amazing build system checks the current module build dates and doesn't rebuild stuff that it doesn't have to? >> So how would your compiler know what libraries to link with? I imagine its >> not a problem if you don't bother with libraries in the first place. > >What, within my language? They are either specified via the module >scheme which lists the source files and libraries used, or infered from >the FFI declarations needed. This is from my scripting language for example: > > importdll sdl2 = > func "SDL_OpenAudio"(ref sdl_audiospec desired, obtained=nil)i32 > ... > end I don't know how .dll works in windows, but on *nix there are a couple of different compiled object types: ".o" are compiled code meant to be merged together to create a binary. ".so" are compiled code which can either be stub linked to the code itself at linktime , or dynamically loaded by the code itself at runtime. Which are you talking about?