That doesn't mean anything.
> Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers
They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
No, people are just inflicting that upon themselves for no good reason. I ship software built with the same clang / libc++ toolchain targetting Mac / Windows / Linux and things works absolutely fine.
Is it an open-source library?
I meant that you can specify symbol versions to link to glibc specifically.
https://sourceware.org/binutils/docs/ld/VERSION.html
> They wanted to support multiple platforms, that multiple platforms implied multiple compilers was part of the portability issues the original goal led to.
He could have used gcc on different platforms too. He writes:
"the platonic ideal portable C exists only as a hypothetical construct in the C standard. The C that exists in the real world is whatever Microsoft, Apple, and others have shipped. That C is a mess"
I.e. his problem could have been solved by sticking to one compiler, be it Rust or Clang ...
You're confusing glibc and GLib...
> He could have used gcc on different platforms too.
That certainly would have solved the multiple platform issue, I'm sure gcc has great and easy support for producing VS-compatible dlls, and that there's nothing an ios dev likes to hear more than "you can use GCC to compile libimagequant".
sanxiyn was talking about GLib, not glibc, and these are two very different projects...
Other implementations may never take off. Python, Node.js, Java, PHP, C#, Golang, Ruby are all more popular and older than Rust, and did not develop fragmentation like C. They have one dominant target, and other implementations have to follow it, or die. Rust's situation is closer to these languages than to C.
But even if there were serious contenders, Rust has already established a strong baseline: there are over 70,000[1] packages that require Rust+Cargo in their current form. A viable alternative has to support them, or it will be niche like mrustc is.
[1]: https://lib.rs/stats
Furthermore, there are big difference in philosophy with C:
1. IB and UB are not considered normal parts of specifications, meaning there's way less opportunity for originality in the interpretation of the specifications
2. there tends to be an ur-implementation, and notable divergences from that tends to be interpreted as either a bug in the other implementation(s) or a lack of specification to be resolved between all implementations
Rust only has UB in unsafe (AFAIK), which greatly limits implementation flexibility in terms of observable behaviour; and the reference implementation would very much be considered the reference implementation, so I expect e.g. rust-gcc will be sticking close to the reference implementation and behavioural divergence will either be fixed to match, or will lead to more precise specification and both implementations converging.
Probably eventually with, if not a Sun-style validation suite, a Ruby-style Spec Suite (https://github.com/ruby/spec).
Use symbol versioning.
Anyway, I feel the author is a bit unfair. He traded supporting multiple compilers for Rust's only and it is not really surprising that he felt that the maintainer burden decreased.
As soon as Rust gets broad adaption I guess there will be subtly incompatible compiler vendors in Rust too.