I think you should check into MinGWTDM64 if you must have a minimal Gnu-Windows 64-bit Gnu Compiler Collection. If you're worried that MinGW32 won't suit your purposes, you're probably misinformed (though I can't be sure what it is that you want to do or whether it's even possible). But I've found that TDM (Dragon?) has done a better job of keeping either up-to-date than the mingw organization itself (at least lately).
If you can't follow the above, it would seem to me to be the more appropriate for you, because the above is very much a reflection of the FSSTND (Filesystem Hierarchy) Standard for *nices. The configure tool is a part of the GNU Build System (q.v. try Wikipedia), so understanding it requires knowing where it expects to find which of its source files on predetermined paths and where to write its target files. This will take you through the setup of the correct header files for your compile in your environment (or platform, machine, OS, etc.) so that it will produce a product (compiler) that will run correctly for you.
Because Gnu's Not Unix (GNU) and Windows certainly isn't, producing a compiler from a single toolset that will work on either is complex (read "breakable"). Building a compiler is not exactly the first step in a developer's career, either. So unless you are prepared for endless heartbreak on a blood-soaked trail (if I might be allowed a little simile), please humour me again while I suggest acquiring a ready-made package.
Have I dissuaded you yet? No, well, don't say I didn't try. The importance of the build tools to your compile is that configure itself is constructed from them. There is very often a set of install instructions (a GNU requirement) that say something like "to build this package (let's say "Hello, World" to keep it in a fairly safe camp) you must first run
$> ./configure
followed by
$> make
That in itself is a gross oversimplification since either may take various parameters as to the type and location of compilers you intend to use and where you intend to install your product. But, let us not diverge too much yet. The instructions will go on to say in many of these packages, "configure was constructed using the autotools set, but it should not be necessary for you to reconstruct it to compile this version of helloworld."
IMHO, "SHOULD NOT" always ought to be capitalized, italicized, boldfaced emphasized and repeated as often as possible. Very often, the only time it should not be necessary to reconstruct configure is when you have an identical platform (architechture, processor, OS and environment) as the author. If you're lucky and the author is thorough, you will occasionally have a clean compile of helloworld on a windows machine even though the author originally built it on a linux machine.
One of the big reasons that I recommend against building GCC (mingw32, 64 or whatever flavour) is that I don't recommend you try to understand autotools without having produced a GNU distribution of your own (even if it's just for practice). Well, you ask, "If I don't even have the compiler yet, how am I supposed to do that?" I can understand your frustration and even share it to a point.
If you still want to have any hope of putting this compiler suite on a Windows machine yourself (without using MinGWTDM or the like), you should first get it to run at home in a Linux environment. Once you see how a build works there, it will become a little clearer. Still I don't see any possibility of you producing a clean compile of the full compiler set (or even a C compiler, really). David Malan at Harvard teaches CS50 remotely using virtualized environments that feel very like and resemble actual installations. It's free and he even teaches C in the process, which will give you an understanding of compiler options (critical to building in varying environments).
If you don't want to run virtualized or you don't get the instructions for building the virtual machine (easier than just building a compiler, believe it or not), you can install some brand of Linux somewhere. I don't recommend doing it on your Windows machine despite possibilities for dual-booting because it can be more destructive than building a compiler or a virtual machine.
Do that and download some Linux source packages from Sourceforge (something highly recommended -- you don't want bad configuration or build scripts). Follow the instructions. Build them on Linux and then repeat the process on windows (you can do it with a 32-bit compiler unless somebody tells you that you can't [99.9% of the time]).
Go to one of the autotools/autoconf tutorials (not the manual pages, do that later to figure out what the exercise meant in detail). Put together your own helloworld package to produce your own configure so that you'll know what it's doing. Do it first under Linux to insure greater chances of success -- then 'port' that to Windows. A word to the wise -- avoid anything with signals -- they're not implemented under Windows and I'm not even sure that my idea for how to do it would even work.
Having said all that, I'm going to say something even more annoying: While the mingw-w64-howto-build.txt is not particularly well-written, it's not as poorly written as it appears to the eye of a novice. As a matter of fact, I'd say that it was written for anything but a novice audience. Since the process of building a compiler from source (especially outside its original home) is not a trivial matter, I'd be surprised if you could find anyone who could explain it to you without using much of the same vocabulary. People who do this sort of thing talk to each other in precisely the same way. They often do a much poorer job of writing than the above -- except when it comes to code and build scripts.
But to address your first question if you haven't opted for a more achievable approach, @prefix@ or whatever it is first called in a script is a kind of "home tree" (a) for build sources, (b) for build targets and (c) for build installs. Unix was based on MULTICS which is its own reminder that Bill Gates' job before Microsoft was working on XENIX, all three being "multi-user operating" or "processor control systems." Multiuser encompasses the notion of multiple accounts, multiple roles, and multiple build/install trees.
Building the compiler for yourself -- especially where the last part of the build is an install procedure -- is going to be different than building it for other users of the same machine. Let's extend this notion just a bit further: Let's say that you're not doing it for yourself and your friends -- you're doing it for your company or more likely, "your installation." Your installation in this case would be something like the base where you are deployed: You not only have to worry about building the compiler for you and your friends who have accounts on your machine -- you have to worry about building it for your boss, your operators, your administrators, your programmers, your designers -- and anybody else who might want/need a compiler to do their work. You may have several types of compilers which must coexist, and the one that you use for experiments, development, production and testing may be different versions and or renditions.
The build and install trees will have a number of things in common. PREFIX attempts to address this. When I build for my own little sandbox, I use a prefix that I set up called ~/local. Thats a special location for *nices. ~ is a shortcut for $HOME or %home% in Windows terms. This is the best place for your practice builds. It should require no special permissions, but there may be some limitations on what lives there. PREFIX doesn't solve all the problems but it gives the configuration tools an idea of where you're going to root the tree of your build and your install. In David Malan's terms, if I'm going to build the code in /home/jharvard/local/<product name>/src (and some versions of some tools will insist on the full path rather than the usual shortcut ~/<product name>/src), my PREFIX for the sandbox compile will be ~/local or /home/jharvard/local and given a reasonable file system standard naming convention, your executables (generated and/or existing) will be in ~/local/bin your libraries will be in ~/local/lib and your include headers will be in ~/local/include while you are just playing around with this in your own account. How did the stuff get into these directories? You built it all there. And you may have borrowed things like your headers from sources such as those cited in the mingw-w64-howto-build.txt file.
Some tools that survive a while get promoted to a broader audience of users: They go into /usr/local/src /usr/local/bin /usr/local/lib /usr/local/include . . . etc.
See the PREFIX? One problem is that to promote to there, you have to be a developer with write permission for that path -- or your configure will fail (among other things).
Some tools have the kind of installation scope that they're not local at all: those might compile from /usr/src to /usr/bin using /usr/lib and /usr/include -- that's another PREFIX.
At the system root where only the Gods compile, tools go into /bin itself, if not /sbin -- these subtrees can be found all over the system on different trees with different purposes -- like /usr/local/experimental/src, /usr/bullpen/development/etc, /usr/production/bin.
I think it's becoming clear why people choose not to answer posts like this, but perhaps this exercise can be useful to a number of people for a great variety of reasons.
As to what default is, it's the default -- you know you're using the default when you haven't used something else. Actually, he's told you what the default is because he's told you "if using configure default /usr/local" so the configure default PREFIX is /usr/local. If you don't use anything else, that means that you type
$>./configure
rather than
$>./configure --prefix=/home/veryambitious/local
and with a few successful builds under your belt, the instructions you cite become clear as mud. For sysroot, sysroot determines where mypath is -- you only have to worry about where you want to build your compiler, install it and run it. As I said earlier, your purpose in wanting to do so (other than just to have one that's up-to-date: There are a lot easier ways of accomplishing that, and getting the latest bugfixes, too). If your goal is just to have a native compiler that's up-to-date, I can't think of any reason to do it at system root -- somewhere either at the top of the hierarchy or at a mount point you plan to call system root. When I build with CMake (a potential competitor for GNU autotools, but not with GNU products, particularly not gcc), it specifies the default install directory as C:\Program Files\somewhere -- I'm sure that's a 'de facto' standard for somebody.
Where your source ends up on your machine depends upon how you acquire it. One version with 'trunk' in the path would be svn-gcc that would be retrieved from a subversion CMS repository. If you got some version of a tarball, your tree could be different. The subversion tree is going to include a lot of stuff you wouldn't get in a 'targeted tarball' like a build tree that is already set up for your environment. However, since it's maintained for software configuration management, it's going to be maintained frequently with up-to-date changes. Sometimes tool-builders add separate 'working snapshots' to duplicate the results of a certain typical environment.
As to the symlinks, that's really a *nice name for a symbolic link that I'm not sure even translates to NT 4.0 in its Windows7 incarnation. A symbolic link is not a hard link in that it does not play a strong role in the definition of an inode, or a file system entity. A symbolic link is a lightweight link that can be deleted and altered without really affecting the original file. What the author is saying about building gcc with links to the *x86_64-w64-mingw32* subtrees is that the files that you will use in your build can be given the generic aliases without building completely different subtrees just to source them.
Your configure error is one of the more generic vanilla error messages that says something rather than saying nothing and leaving you to figure out that you're missing most of what you need. It means, "I can't tell you what went wrong, but I can't find anything that I need to begin to read and produce files. This must be a weird environment because I don't see anywhere to read or write. Maybe you missed the header files -- are you sure you put them in the right place(s)? If not, maybe this is a machine, operating system, or environment that hasn't been defined for me." This does really come up in real life, because people build cross-compilers on one machine that will be hosted on another machine. Or for code that will be hosted on another machine. In these cases, you would need to add configure options --build=mybuild (please don't ask me where that is) and --host=myhost.
Usually it just means that you're doing it all wrong and you have to follow the instructions for building gcc that matches your entire configuration. There are many ways of doing that -- you mention MINGW, but that's not the whole story. You need internal functions that come from Windows APIs. The Cygwin DLL included a bunch of these -- I don't know whether anyone is working on that anymore. MSYS uses a similar approach, but does not provide the full cygwin set. You don't have UNIX system routines, so you need some replacement -- that can be provided easier on Linux than on Windows.
Your target will produce executables that will be run with the assistance of the MSVCRT (Microsoft Visual C Runtime) which is another wrinkle in the standard results. Sometimes even if you have the latest GCC, MSVCRT hasn't caught up yet. Sometimes they just choose to ignore standards, say, in size parameters of format conversion strings -- maybe they think you should be customising streams -- who knows?
I guess I'll mark this as a community post since I'm sure that there's a good chance that I managed to type something supremely stupid. I hope I've shed some light on how compiling GCC on windows is not going to be an "out of the box" endeavour. There's no way I could cover it all, so I just littered this page with clues.
Best Answer
sys/socket.his a POSIX/SUS header. MinGW is for building WinAPI executables. Either switch to building with Cygwin's GCC to get access to POSIX/SUS facilities, or switch to using WinAPI'swinsock2.hinstead.