GCC Gets a New Frontend for Rust (fosdem.org) 106
Slashdot reader sleeping cat shares a recent FOSDEM talk by a compiler engineer on the team building Rust-GCC, "an alternative compiler implementation for the Rust programming language."
"If gccrs interprets a program differently from rustc, this is considered a bug," explains the project's FAQ on GitHub.
The FAQ also notes that LLVM's set of compiler technologies — which Rust uses — "is missing some backends that GCC supports, so a gccrs implementation can fill in the gaps for use in embedded development." But the FAQ also highlights another potential benefit: With the recent announcement of Rust being allowed into the Linux Kernel codebase, an interesting security implication has been highlighted by Open Source Security, inc. When code is compiled and uses Link Time Optimization (LTO), GCC emits GIMPLE [an intermediate representation] directly into a section of each object file, and LLVM does something similar with its own bytecode. If mixing rustc-compiled code and GCC-built code in the Linux kernel, the compilers will be unable to perform a full link-time optimization pass over all of the compiled code, leading to absent CFI (control flow integrity).
If Rust is available in the GNU toolchain, releases can be built on the Linux kernel (for example) with CFI using LLVM or GCC.
Started in 2014 (and revived in 2019), "The effort has been ongoing since 2020...and we've done a lot of effort and a lot of progress," compiler engineer Arthur Cohen says in the talk. "We have upstreamed the first version of gccrs within GCC. So next time when you install GCC 13 — you'll have gccrs in it. You can use it, you can start hacking on it, you can please report issues when it inevitably crashes and dies horribly."
"One big thing we're doing is some work towards running the rustc test suite. Because we want gccrs to be an actual Rust compiler and not a toy project or something that compiles a language that looks like Rust but isn't Rust, we're trying really hard to get that test suite working."
Read on for some notes from the talk...
"If gccrs interprets a program differently from rustc, this is considered a bug," explains the project's FAQ on GitHub.
The FAQ also notes that LLVM's set of compiler technologies — which Rust uses — "is missing some backends that GCC supports, so a gccrs implementation can fill in the gaps for use in embedded development." But the FAQ also highlights another potential benefit: With the recent announcement of Rust being allowed into the Linux Kernel codebase, an interesting security implication has been highlighted by Open Source Security, inc. When code is compiled and uses Link Time Optimization (LTO), GCC emits GIMPLE [an intermediate representation] directly into a section of each object file, and LLVM does something similar with its own bytecode. If mixing rustc-compiled code and GCC-built code in the Linux kernel, the compilers will be unable to perform a full link-time optimization pass over all of the compiled code, leading to absent CFI (control flow integrity).
If Rust is available in the GNU toolchain, releases can be built on the Linux kernel (for example) with CFI using LLVM or GCC.
Started in 2014 (and revived in 2019), "The effort has been ongoing since 2020...and we've done a lot of effort and a lot of progress," compiler engineer Arthur Cohen says in the talk. "We have upstreamed the first version of gccrs within GCC. So next time when you install GCC 13 — you'll have gccrs in it. You can use it, you can start hacking on it, you can please report issues when it inevitably crashes and dies horribly."
"One big thing we're doing is some work towards running the rustc test suite. Because we want gccrs to be an actual Rust compiler and not a toy project or something that compiles a language that looks like Rust but isn't Rust, we're trying really hard to get that test suite working."
Read on for some notes from the talk...
- It reuses the GNU toolchain — the gdb debugger, the as assembler, and the linker ld — while also reusing official Rust libraries like libcore, libstd, and libproc.
- "Because of the way GCC is architectured, once you get to that common GCC backend and common GCC intermediate representation, you can basically reuse all of the plugins that have been written for GCC ever. And that means a lot of plugins — security plugins, stuff like the static analyzers, the LTO (link time optimization), CFI security plugins, and so on."
- "We also hope that because we're writing it in C++, that means we can backport it to previous versions of GCC. And hopefully that will help some systems get Rust."
- "Because GCC is much older than LLVM, it has support for more architectures and more targets than LLVM. So technically thanks to gccrs, you will now be able to run Rust on your favorite Soviet satellite and so on."
Compilers are awesome (Score:5, Funny)
What other application can you ship that can casually include the phrase " you can please report issues when it inevitably crashes and dies horribly." And people are nodding along going "well yes of course perfectly reasonable".
Mad respect to everyone who works on compilers.
Re: (Score:2)
I would say that any application you're involved in should at least casually include that phrase. I'd expect more from a faux emacs user.
Re: (Score:2)
What other application can you ship that can casually include the phrase " you can please report issues when it inevitably crashes and dies horribly." And people are nodding along going "well yes of course perfectly reasonable".
Games from Ubisoft. ;)
Re: (Score:1)
Games from Ubisoft. ;)
Ha!! :-)
Re: (Score:2)
Cue the C++ conspiracy theorists (Score:1, Troll)
We've already seen em on slashdot before. Basically their idea is that rust is going to marginalize C++ into a second class citizen as part of their C++ replacement theory. But this isn't true because C++ is already a second class citizen. C developers have for a long time maintained that C++ has no place in the kernel. But now that rust has been allowed in, that makes C++ developers very sad.
Re: (Score:1)
C developers have for a long time maintained that C++ has no place in the kernel. But now that rust has been allowed in, that makes C++ developers very sad.
As a C++ developer, I'm glad the kernel devs have finally come to their senses and realised that C is not the be-all and end-all of languages. If there's one thing a C++ developer like me thinks it's that writing C is an exercise in tediously doing the same things over and over and over again by hand that you could automate away with the compiler at zero
Re: Cue the C++ conspiracy theorists (Score:2)
If you take away all the things that cant be used in the kernel - ie the entire STL, exceptions, virtual functions - then C++ is little more than C with classes again.
Re: (Score:3)
Kernel runtime is different from application runtime so this is expected. There is nothing inherently wrong with C++ language when it comes to kernel programming. It is just that the toolchain is not designed for kernel runtime and the resulting object code is problematic when it comes to kernel development. They had to make changes to Rust toolchain to make it suitable for linux kernel as well.
This is an old paper from Microsoft that outlines problems of using C++ for kernel development: kmcode.doc [microsoft.com]. It
Re: Cue the C++ conspiracy theorists (Score:3)
As a C++ developer, I'm glad the kernel devs have finally come to their senses and realised that C is not the be-all and end-all of languages. If there's one thing a C++ developer like me thinks it's that writing C is an exercise in tediously doing the same things over and over and over again by hand that you could automate away with the compiler at zero cost.
I don't even understand the language wars to be honest. Actually the whole reason I started using rust was because I was using the wrong tool for the job, repeatedly. At the time, all I knew was java and C#. Java was really pissing me off (and still does when I need to use it) and while C# was much better, it still had a problem in common with java: Too often, when you need to give somebody a tool you've written, they don't have the right runtime installed. Java is even worse because it routinely breaks com
Re: (Score:2)
Dependency management is a hard problem in general, and, IMO, one of the generally tedious and painful parts of managing production software through its expected lifetime.
I find it a little easier in "batteries-included" environments like C#/.NET Core (among others) because most of the time I don't need a lot of external libraries and I have the option of choosing ones that don't have a lot of external dependencies themselves.
Re: Cue the C++ conspiracy theorists (Score:2)
Yeah the batteries included part is nice, and C# does a better job than most. Especially when compared to java (dependency shading -- 'nuff said.) Though rust's reasoning for having a very small standard library is a very, very good one.
And rust actually draws a ton of inspiration from C#, particularly with async/await. Likewise, adding dependencies to your project in rust is dead simple if not easier than C# (namely, no xml required.) But still, a lot of times I wish there was a batteries included extended
Re: (Score:3, Funny)
> C developers have for a long time maintained that C++ has no place in the kernel.
That's because C developers are arrogant pricks, especially the ones named Linus Torvalds :)
Re: (Score:2)
Nonsense. Results of his work aside, Torvalds always separates a person from their behavior. He may say that some code is absolute shit and that the person who thinks that code is OK is "out to lunch".
And I say that as someone who codes in C++ all the time (except for golang when it comes to tedious system stuff), and I think his anti-C++ stance when it comes to the Linux kernel is spot on. Don't know what he thinks about rust, but the people who push for it seem to have an ideological bend that has nothing
Re: (Score:2)
Re: Cue the C++ conspiracy theorists (Score:2)
Re: (Score:2)
Re: Cue the C++ conspiracy theorists (Score:2)
Actually this is literally the only place I talk about C++ at all, and it only comes up because of two particular douchebags that I guarantee you will comment on this topic, as they do for everything else rust. I talk about C outside here occasionally because I've written API's for C code (or any code that interacts with C) but other than that, it's never a topic. But congratulations, you've just been triggered.
https://youtube.com/watch?v=p7... [youtube.com]
Re: (Score:1)
Even though the last time we argued on this topic, I was very much NOT an AC. He'll never let that fact affect his own conspiracy theory, while he accuses others of having them.
Re: (Score:1)
You're so shit in your understanding of how programming languages and software development works that you have no idea how much of an embarassment you are.
So Rust does not even have a spec? WTF? (Score:4, Insightful)
"If gccrs interprets a program differently from rustc, this is considered a bug," is very much _not_ the way to do it. Some people aggressively insist on making the same, old, well-known mistakes again and again it seems.
Re: (Score:2)
The C or C++ versions of the same project are way better in every conceivable way.
This is...unlikely.
Re: (Score:1)
That's The Evil Atheist. He posts as AC on this topic now because his name became mud after he repeatedly made comments exactly like what you replied to.
Re: (Score:2)
He is correct about the CVEs though. Rust has quite a few CVEs and some of them are an indicator of really dumb (and arrogant) language designers and tool developers. Given that Rust has low adoption, that number of CVEs is a really bad sign, especially as the claim is that Rust is production ready. Either it is not yet in a production ready state (in which case the people claiming so are liars, not good) or it is fundamentally flawed (which is worse). Given that some people praise it beyond all reason, I s
Re:So Rust does not even have a spec? WTF? (Score:5, Interesting)
The lack of spec is certainly a problem and it is certainly true that the safety of Rust is overstated by pretending that memory safety is all that matters. Also there is still selection bias: You can really compare new Rust code written by a highly motivated (and certainly expensive) team to average C code. So I think a real proof that Rust improves security in practice and under equal conditions (cost) is still outstanding.
Nevertheless, I still think there are real safety benefits to Rust and the number of CVE may not reflect this. Te Rust CVEs are often for issues affecting memory safety, even if the problem itself is not an exploitable security issue. It is definitely a failure of the C, C++ ecosystem to address memory safety issues properly. This is starting to change though, in part thanks to the Rust people.
Re: (Score:2)
.. can *not* really compare..
Re: (Score:2)
Well, at this time, I do not expect this to pan out anymore. Rust had enough time to fix its act and it failed. Aggressive marketing cannot replace technological quality.
That said, there is no memory safety issue with C (or C++). There is a developper quality issue. The reference projects that show it can be done right exist. Of course, C (C++) should only be used if you need the memory model it uses or the control over performance. Using the wrong tool for a job will cause problems that are not the fault o
Re: So Rust does not even have a spec? WTF? (Score:2)
How has rust failed? Its adoption is spreading very fast. In fact, some very big name companies are already increasingly using it. Industrial, aviation, games...You name it.
Oh and when I troll these topics, it's meant to keep dumb and dumber occupied and sidetracked. I've got one of them engaged in a different thread. I'm talking him through his existential crisis so that the rest of the topic can proceed uninterrupted.
Re: So Rust does not even have a spec? WTF? (Score:1)
Re: So Rust does not even have a spec? WTF? (Score:2)
With C theres no memory safety issue in that theres no memory safety, end of. C is a very powerful gun with a hair trigger permanently pointed at your foot. With C++ the trigger is slightly less sensitive.
Re: So Rust does not even have a spec? WTF? (Score:2)
Re: So Rust does not even have a spec? WTF? (Score:2)
Can you link to these CVEs? Reason I ask is because whenever people refer to ones that they blame on rust, it's actually not rust code that's at fault. Rather, a transitive dependency that isn't written in rust is at fault, and because of that, rust gets tagged as the language being used.
And why are you saying rust developers are arrogant? Who in particular is?
Re: (Score:2)
I don't know whether any particular developer is arrogant, but the Rust community certainly is. Perhaps it's just fanboys, but not being that interested in Rust, I've no way to tell.
(OTOH, Rust was among the languages that I considered for my current project. I considered C, Python, Ruby, Rust, D, Java, and C++. I picked C++. I would have considered Julia, but I couldn't find good enough documentation.)
Re: (Score:2)
From Rust Vulnerability Analysis and Maturity Challenges [cmu.edu]:
A MITRE CVE search for "Rust" [mitre.org] in December 2022 returned recent vulnerabilities affecting a wide range of community-maintained libraries but also cargo itself, Rust's default dependency management and software build tool.
Perhaps one of Rust's most noteworthy features is its borrow checker and ability to track memory lifetimes, along with the unsafe keyword. The borrow checker's inability to reason about certain situations around the use of unsafe code can result in interesting and surprising vulnerabilities. CVE-2021-28032 [mitre.org] is an example of such a vulnerability, in which the software library was able to generate multiple mutable references to the same memory location, violating the memory safety rules normally imposed on Rust code.
While this is only one example, other CVEs appeared for undefined behavior and other memory access errors in our basic CVE search. These existing CVEs seem to confirm our earlier observations on the limitations of the Rust security model [cmu.edu]. While it is hard to compare Rust-related CVEs to those of other languages and draw general conclusions about the safety of the language, we can infer that Rust's memory safety features alone are insufficient to eliminate the introduction of memory-related software vulnerabilities into the code at build time, even if the language and compiler do well at reducing them.
For example, Rudra discovered CVE-2021-25900 [mitre.org], a buffer overflow in the smallvec library, as well as CVE-2021-25907 [mitre.org], a double drop vulnerability (analogous to a double-free vulnerability due to Rust's use of default OS allocators) in the containers library.
Re: (Score:1)
Re: (Score:2)
I think the question is how often do CVEs occur in the first place. How long do they take to get fixed is also an interesting question but a different one.
The problem with all of this, of course, is that there is more than one interpretation of the number of CVEs. If you look hard at a piece of software, and stress it lots, then over time, you will find more bugs, it will have more CVEs. That's a good thing.
The second problem with this interpretation in Rust, is that it has a fairly small standard library.
Re: (Score:1)
Re: (Score:2)
He is correct about the CVEs though. Rust has quite a few CVEs and some of them are an indicator of really dumb (and arrogant) language designers and tool developers
Python has shown very clearly and conclusively that dumb language designers and tool developers are in no way a barrier to mass adoption.
Re: (Score:1)
Cases certainly still exist now where if you just copy the "official" implementation then you are violating the spec because the "official" implementation aint perfect.
I suggest these gcc guys create a language specification, name it "crust", and do a good faith effort of defining something concretely that is at least mostly compatible with rust, that where it differs it is because it offers a path to a solution to real world in
Re: So Rust does not even have a spec? WTF? (Score:2)
Re: (Score:2)
No, that's not me as an AC.
I NEVER post as AC.
Seems like you can't hack the fact that I severely whooped your ass the last time you ended up exposing how little you know about how programming languages work.
Re: So Rust does not even have a spec? WTF? (Score:2)
Only, you didn't.
Re: (Score:2)
You have issues dude. And you know jack shit about how programming languages work, or software development.
Re: So Rust does not even have a spec? WTF? (Score:2)
You say that, but between the two of us, you're the only one to demonstrate it.
Re: So Rust does not even have a spec? WTF? (Score:2)
Folks, just do a problem challenge. The energy going into your conflict is wasted because you do not acknowledge each other's posts.
Re: (Score:2)
Re: (Score:2)
Maybe referring to the essential libraries for Java? I'm not an expert in anything, but it certainly seems PHP took over from perl in web dev because the libraries were generally not confusing, or they were built-in. Perl libraries are the gold standard of old-school OSS for me, but PHP turned out to be more practical, whatever its mishmash of function names and parameters. Sessions for example were just done right, though they're not used much now. Yes I know this discussion is about compiled languages, bu
Re: (Score:2)
(a.k.a. Delphi)
Re:So Rust does not even have a spec? WTF? (Score:5, Interesting)
If people keep on doing it, perhaps that is because it is not such a big mistake as you think.
The original reason that specifications were so important it that it gave a single source of truth, which mean that you were not tied into one vendor. That was a great idea, of course, but there are a number of flaws with it. First, for many languages, vendors simply add new "features" which are not standard. Next, many specifications have holes and other undefined behaviour which different vendors handle in different ways. Both of these means you get vendor lock in anyway.
Finally, of course, if the implementation is freely available under equitable and non-revocable terms, vendor lock in is rather less of an issue. The implementation and its documentation become the source of truth and the language can evolve more rapidly. That is, perhaps, why many of the top used languages were not designed specification first: python and javascript are both examples.
Rust, of course, has a specific set of aims and some of those would be served by having a specification which is why one is being written.
I don't think this is a mistake; it's a decision and like all engineering decisions one that involves compromises.
Re: (Score:2)
I think to have a spec for rust would require going over quite a lot of historical ground. At this point in it's evolution, the language is what it is, but changes to the language are clearly documented, working their way through an RFC process, with a specification and implementation phase.
To me this feels like the question many had over Rust not having GC -- folks from the relevant background jumped up and said "why would you want a language with manual memory management". Well, good question, in general,
Re: (Score:2)
That is not how this works. What a spec does is tell you which language state the compiler can handle and what the semantics at that stage are. There _can_ be several spec evolution stages and you just tell the compiler for which version to compile.
In the absence of a spec you can rely on, you are forced to follow all the changes in detail and on every change evaluate whether you need to rewrite your code and that is a lot of effort and can fail. Any change that just does not simply add separate things can
Re: (Score:2)
Interesting. And, yet, many languages do exist which are widespread to some extent or another and in heavy use. None of the three that I use most frequently (python, clojure, rust) have specifications and I have have not had the problems you describe. Of these three, rust provides fairly strong forward compatibility guarantees -- the code that I wrote in 2018 will still compile with a 2023 compiler. Conversely, in a language with a specification, in practice everything that you say is true also. C for examp
Re: (Score:2)
The comparison to Python is invalid. Python is not a systems programming language and its core functionality has been stable for a long, long time, except for the move from 2x to 3x, which was done very publicly and over a long time. With the nature of Rust and the claims being made about its nature, capabilities and state, a spec cannot be done without. Or some of these claims become lies.
Re: (Score:2)
Curious. None of the comments that you made early where specific to systems programming languages. And python has been stable for a long time, except for the change from 2 to 3, which feels a pretty big except. Likewise, I think, it is unfortunate that you use a term like "lie"; this is not the same thing as a a statement which someone else thinks is untrue.
Anyway, I am clear on your point of view now, and have got slightly deeper than "if it doesn't have a spec it's wrong". I agree with you that stability
Re: (Score:2)
If people keep on doing it, perhaps that is because it is not such a big mistake as you think.
And at that point I stopped reading. You have nothing but an invalid AdHominem. And you are clearly incompetent as to language development. No, it is not "me" "thinking" that. It is a clear and well-know part of the state-of-the-art.
Re: (Score:3)
That's not really fair. I generally don't have a spec when I start, and often do lots of radical redesigns during development. When I get things right, THEN I write a spec. If you start with the spec you're likely to promise things you can't do, and leave out important things that you could have done.
But the spec should show up before you consider the work out of alpha. Beta, et seq. should avoid massive changes in how things operate. And breaking changes should be avoided firmly after about half way t
Re: (Score:2)
The claim is that Rust is "production ready". At that time it needs to have a spec. What about that is "not really fair"?
Re: (Score:2)
It is not an ad hominen attack. The "you" could refer to anyone. I am simply asking you, what it is about the absence of a spec that worries you. What are you trying to achieve that the lack of a specification makes impossible, or difficult?
I am not a language developer, that is not my job, my expertise. I am a language learner, and a developer. I want to understand what impact you think the lack of a spec has on me, and what not only makes it "state-of-the-art" today, but also state of the art tomorrow. I
Re: (Score:2)
Stop claiming nonsense. My answer was completely clear. Also, you may want to look into language design and evolution for a while, which is something I can obviously not summarize in a few lines.
Re: (Score:2)
I haven't claimed anything. I have asked something, which was an explanation.
As far as I can see, your argument is this:
Rust is bad because it does not have a spec
The need for having a spec is a clear and well understood
And, yes, despite this many other languages have not had a spec. This was and is a mistake in every case.
Okay, that's fine. I am saying:
Rust has reference doc and reference implementation
Rust has a process for change management
The rust implementation is freely available
A specification is bei
Re: (Score:2)
Seriously? You expect me to state what probably would fill a 45 min lecture in a few sentences? And if cannot, then you are right? That is not how reality works.
Some aspects you will find in my other answers here. Some others are obvious if you stop trying to argue with the misconception that obvious Rust must be great. For example, how many systems programing languages without a spec (which does not need to be a formal one) do you know? And there are more aspects to this. You also need to be aware that you
Re: (Score:2)
It is possible to summarize most things. Anyway, you have provided an explanation of at least one of the problems that you see in another post and that has been useful.
In terms of systems languages without a spec, I think, this will turn into a non-true-scotsman fallacy, because I can just say "rust". Even without this, the past does not prove the future. In the past, formal specs were considered vital in many areas that they are not now.
Finally, on the sunk cost fallacy, I don't think you can know whether
Re: (Score:2)
In the past, formal specs were considered vital in many areas that they are not now.
You are misguided. The problem is with today's social networking you have a lot of people being loud about things they do not understand. A spec is _still_ a requirement for any serious system programming language that claims to be production ready. A requirement by anybody actually competent in the area. The arguments for it have not gone away. There are no new arguments against it, just the same ones that were already invalid before. There are a lot of people that have no clue about established wisdom in
Re: So Rust does not even have a spec? WTF? (Score:1)
Re: (Score:2)
And were id I say the spec needs to come first? Oh, whait, I did not. The point is that when a language is claiming to be production ready, it needs to have a spec. If it does not have one, then it is still experimental and unsuitable for anything except experimental things. Make a choice. Is Rust unfinished and experimental or is it ready for production? You cannot have both.
Re: (Score:2)
So Rust does not even have a spec? WTF?
Yes, that's actually why efforts to make a GCC frontend were dropped in 2014: the language was being changed so quickly that they couldn't keep up.
Eventually a 1.0 language reference (which isn't a specification) was released and the new GCC Rust is based on this. It's not ideal but it's a fixed point rather than an ever evolving language which makes it psuedo-specification.
"If gccrs interprets a program differently from rustc, this is considered a bug," is very much _not_ the way to do it.
Part of the GCC Rust effort is to find where the reference is ambiguous (and thus interpreted differently) so that there can eventually
Re: (Score:2)
I applaud the efforts to make a specification even if they are going about it all wrong. This effort will either force them to do it correctly or be the death blow that destroys any possible future for it.
I agree to that. For Rust to ever amount to anything, they have to finally get it out of the experimental stage and that means a specification that people can rely on. Just claiming it was ready for production does in no way make it so.
Re: So Rust does not even have a spec? WTF? (Score:2)
It's a Rust thread, I come here to laugh at Gweihir's harumphing.
Re: (Score:2)
Blessed are the clueless, for they shall be forever amused at things they do not understand....
Comment removed (Score:5, Informative)
Re: (Score:2)
That and when C was done, nobody really understood how to do it. That is different today. Well, many people still do not understand how to do this and Rust is an example of that.
Yes, Rust is unstable and experimental at this time. What is not acceptable is the designers lying about that fact.
More bloat. (Score:2)
I have a Linux box, running Gentoo, that has been running for about 14 years now.
The time to build Gcc on this box has gone from less than 3 hours to over 30 hours. It's made worse by the fact that, with only 2G of RAM, I have to use "-j1" or it runs out of memory. Even back in 2018, it was less than 8 hours, but has taken a big jump since then.
This just looks like another thing that will increase the time to build Gcc.
Re: (Score:2)
Re: (Score:2)
That’s why software today has the same load time as it did 30 years ago running on slow platter drives. Computers and memory are orders of magnitude faster and yet it never feels faster.
Re: (Score:2)
Re: (Score:2)
Compile times can be an issue on Gentoo because it's source-based, and updating a package usually involves re-compiling it. Big packages like gcc, llvm, firefox, chrome, and kde can take hours if not days if the hardware isn't enough for the compiler to work efficiently.
I have 3 Gentoo boxes at home. One is fine. Another is old, but I was able to add RAM and an SSD, and it is now fine in spite of an old-ish (i5-3570) CPU. But the one machine I intended as a "spare," and was underpowered even when I got
Re: (Score:2)
You can select which languages to build using ./configure --enable-languages=c,c++,...
So simply turn it off.
In terms of build times (and IMHO also otherwise), it was certainly a bad decision to switch GCC to C++.
Re: More bloat. (Score:2)
Gentoo? The Linux with the built-in system for compiling shit across multiple machines? That's the system you're having trouble with compiling on 2 GiB of RAM?
Definitely sounds like user error.
Re: (Score:1)
Gentoo? The Linux with the built-in system for compiling shit across multiple machines?
It just uses distcc, you can run that on any Linux you want. Most computers have enough cores that it isn't that important any more, though. The last time I used it (and gentoo) was when I owned a K6/2 laptop. Then it was really important to do your own build (a K6/2 is a terrible P2, but it's faster clock for clock than a P2 if you optimize for it) and I also had a much less limited desktop available to do my computation. I've also used it with an ARM system and a cross-compiler on a remote system, which i
Re: (Score:2)
Re:More bloat. (Score:5, Insightful)
If you want a tiny compiler with no "bloat", i.e. features, use tcc.
GCC's optimizer is huge and complicated and it also does an incredibly good job of making code fast, so you can write, the short, clear, obvious thing and have it run faster than some supper l33t tricky code. GCC's front end is pretty complicated now too, with extensive warnings (turning into a small static analyzer), "did you mean" suggestions, and the ability to track a warning found deep in the levels of the optimizer back to the exact character of the input.
And GCC has also got a lot faster in the last 14 years, so your code builds quicker.
All of those things make developing code better. It even makes you ancient machine more effective so that the code you build builds faster and runs faster.
I don't really see why we should hold back meaningful, useful progress because you are running a substantially less capable computer than one that would cost you less than 100 GBP new. Even if you desperately don't want to upgrade (I built GCC 12 recently on my 13 year old machine but I have 16G), you can rent a 64 core machine for less than $1 per hour from google, build GCC there and copy it over (yep GCC install trees can be copied around just fine, thanks GCC devs!!).
Re: (Score:2)
So get an AMD FX chip, those are the last ones without a management processor but new enough to have an IOMMU. I just recently sold a bundle of everything but the case and storage with 32GB and a FX-8350 (8 cores) for $170. It is now a friend's home server.
Re: (Score:2)
I have a Linux box, running Gentoo, that has been running for about 14 years now.
The time to build Gcc on this box has gone from less than 3 hours to over 30 hours. It's made worse by the fact that, with only 2G of RAM, I have to use "-j1" or it runs out of memory
I just recycled a better computer than that. You can literally get a superior replacement for free by scrounging anywhere in the developed world.
Re: More bloat. (Score:2)
rPI sounds like a more capable computer TBH. And it can probably use microsd cards that are both higher capacity and faster than whatever spinning disk runs on that.
Re: (Score:2)
Just turn off all the front ends that you don't need. Are you going to be doing a lot of work with Fortran? Ada?
Re: (Score:2)
I would not run Gentoo in less than 16GB. It can handle a modestly old CPU, but sufficient RAM is absolutely essential because that's what compilers need.
LLVM (which gets rebuild on my systems much more frequently than GCC) takes a little over an hour on my 3 year old machine which was fairly state of the art at the time. But on my 5 year old machine with no SSD, limited RAM and crap CPU, it can take well over a day.
Not Guilty (Score:2, Funny)
I shot no one with this gun in my hand.
Soviet satellite? (Score:2)
> So technically thanks to gccrs, you will now be able to run Rust on your favorite Soviet satellite and so on."
Soviet satellites have plenty of rust already :)
GCC (Score:2)
Now with corrosion inhibitors.
rustc does much more than analyse and compile code (Score:2)