I mean that if you always use same libc you only have to read it once, but if every problem have its own you have to read all of them. I do not think it changes it sucklessness. I just wasn't sure whether the reason was to have a single compilation unit or if there was some other point to it (as both was listed as futures).
Although I do not expect you to do so. I would break out the libc to a standalone project or, depending on how well it would work (and if most of it could be done with a script), fork musl-libc and make it a header-only (+crt) library. Regards, Mattias Andrée On Tue, 10 Sep 2019 19:15:12 +0000 sylvain.bertr...@gmail.com wrote: > On Tue, Sep 10, 2019 at 06:48:17PM +0200, Mattias Andrée wrote: > > What is the point of doing your own mini-libc within the > > program? Aren't you just making it less portable and > > adding more code to read? > > More code to read? Have you read the code of a standard libc? Not to mention > the SDK deps? Moreover, this "mini-lib", as you said it, is actually compiled > as 1 code unit with the application code (on a pi3 for the aarch64 port in a > few secs, max optimization, lol). Hardware portability code is really thin, > and > linux devs are smoothing that out (it's a WIP). > > I personally use it on x86_64 (my station) and aarch64 (pi3). > > Your question feels a bit like the following one : what's the point of > suckless? > > In the end, if this does not fit your definition of suckless, don't bother and > just look away, don't be offended, I do not expect less. > > Btw, I have also the receiving part but the code is quite older: > https://rocketgit.com/user/sylware/lnanosmtp I just did a bit of refactoring > for the "1 compilation unit" suff and some updating (I personally use it on > aarch64). As I did explain, gogol did a fine job at pushing me coding all > that. >
