Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have successfully built both MPFR and GMP and both works well. I then try to build binutils as explained on the http://wiki.osdev.org/GCC_Cross-Compiler wiki page. I successfully complete the configure part but when I try "make all" I get this:
archaos90 wrote:Can someone explain the source of this error and perhaps a solution for it?
It's a small glitch in the brain that makes people scroll down the directory listing all the way to "binutils-2.9", not perceiving the "binutils-2.20" a bit up the list, and not wondering about either the 1998 file date nor the missing of any mention of "binutils-2.9" in the "Tested on..." table of the GCC Cross-Compiler Wiki page.
This error is quite common, actually.
Every good solution is obvious once you've found it.
archaos90 wrote:Can someone explain the source of this error and perhaps a solution for it?
It's a small glitch in the brain that makes people scroll down the directory listing all the way to "binutils-2.9", not perceiving the "binutils-2.20" a bit up the list, and not wondering about either the 1998 file date nor the missing of any mention of "binutils-2.9" in the "Tested on..." table of the GCC Cross-Compiler Wiki page.
This error is quite common, actually.
Good thing I always kept looking at the dates because I always found the source package names were so obfuscated.
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
I, on the other hand, accept the existence of this problem although I can't really understand it. To the contrary, I find any numbering scheme employing leading zeroes to "align" version numbers to be pretty retarded.
But let's be quiet about this all before the lockhammer finds us.
Every good solution is obvious once you've found it.
Hobbes wrote:I don't consider it retarded as long as computer sort file names alphabetically.
Uh-huh. And how much "zero fluff" do you intend on adding so that it doesn't clutter the version string and isn't exhausted too soon?
Versioning without leading zeroes has been around before half of the visitors here touched their first keyboard. IMHO, computers making things simpler haven't kept up with computer users getting dumber.
Edit: Or rather, an unfortunate attempt to make operating systems and applications smarter has resulted in a tendency of people wanting to use their computers with their eyes and brains shut off.
Edit 2: That's not to be constructed to be an attack on the OP, but blaming the versioning scheme or the way the computer lists data for the human mistake made. All the attempts at making it "simpler" (leading zeroes, "automagically" correct listing of versions) just make it more convoluted ("fluff" in version numbers, inconsistent listings).
Last edited by Solar on Mon Oct 19, 2009 12:30 pm, edited 1 time in total.
Every good solution is obvious once you've found it.
Why couldn't they do 2.0.9 and 2.2.0? They still get their versioning system (just with an extra dot) and if there's any software that gets to x.10.y then it really should have gone to x+1 a long time ago. I don't understand many of the OSS community's (IMHO) stupid paradigms, and this is one of them. It doesn't make things easier, and yet everyone does it. Surely there's a better way?
Major.Minor. That way of versioning things is literally as old as the idea of versioning, introduced by SCCS in 1972. You don't bump the major just because the minor grows an extra digit. I am not quite sure when they attached a patch number, but it was a logical expansion of the system, and has been used consistently and ubiquitously for, I'd say, about two and a half decades.
While I am not opposed to change on principle, I think anyone who wants to get more involved with software than simply click on his package manager to "update to latest version" should be able to figure this scheme out, or try something else as a pastime.
Every good solution is obvious once you've found it.
It's not really the only retarded thing that persists solely because of tradition. Take for an example the GPL. Sure, the BSD license is slowly but surely beginning to replace it. GPL still sucks and is - literally - a virus among licenses. Stallman sure did great things once a long time ago. I just don't like his legacy. And why can't every GCC-toolchain support most executable formats by default, for example? Can't really hurt, can it? At any rate, my point is that there's much one can get so frustrated over, just because of stupid traditions and principals that really needs upgrades... just like all the software they're attributing. Welcome to the Age of the Digital Beauracracy - where the tradition omits the upgrade. It's just the way the development goes and we - the programmers - go with the flow, because a programmer... is one lazy bastard, and we all know it. cludge-cludge-cludge
archaos90 wrote:And why can't every GCC-toolchain support most executable formats by default, for example? Can't really hurt, can it?
Because 99% of the users only ever need the native format, and what you don't compile in, you don't have to test and support (from the view of the distro maintainer).
The opposite of "not all features activated by default" is called bloatware, and one of the things we keep flaming Microsoft for....
Every good solution is obvious once you've found it.
