Fix ghci crash when the user code closes stdin

Now that we share stdin with the program, we have to check for
handle-closed as well as EOF, as the program might have closed
stdin.
Detect linker information at runtime. Fixes Trac #6063

Previously, we did ./configure time checks to see if 'GNU ld' supported
certain options. If it does, we bake those options into the link step.
See Trac #5240.

Unfortunately, the linker we use at runtime can change for several
reasons. One is that the user specifies -pgml 'foo'. The other is if
/usr/bin/ld or whatnot changes from when GHC was built.  Those options
mentioned earlier are specific to GNU ld, but many systems support GNU
gold too. This is Trac #6063.

So we need to check at runtime what linker we're using. This is actually
a little bit complicated because we normally use the C compiler as our
linker. Windows and OS X are also special here.

Finally, this patch also unconditionally gives '--hash-size=31' and
'--reduce-memory-overheads' to the system linker if it's GNU ld. These
options have been supported for 8+ years from what I can see, and there
are probably a lot of other reasons why GHC would not work with such an
ancient binutils, all things considered.

See Note [Run-time linker info] in SysTools for details. There are
plenty of comments as well in the surrounding code.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
Release note blurb for Linker fixes.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
Add some missing clang bits to the build system.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
Work-around clang weirdness by adding a newline.

I really wish this were a joke, but alas...

This gets me a working stage1 compiler on Linux with Clang with no
modifications. Unfortunately it won't get much farther than that for
various other reasons.

Signed-off-by: Austin Seipp <aseipp@pobox.com>
Have GHC depend on the stm package
Atomically increment the UniqSupply counter
Atomically update the name cache in tidyTopName

To pave the way for parallel --make, we need to make sure that all
modifications of shared mutable state are performed in a thread-safe
manner. This is one of such occurrences.
Make newTempName thread-safe

There is an obvious race condition between checking whether a file
exists and having the caller of newTempName bring the file into
existence so that it will have exclusive access to that file.

To remedy this, introduce nextTempSuffix to keep track of the next
unique suffix that a new temporary filename ought to have.
Make cleanTempFiles/cleanTempFilesExcept thread-safe

Atomically update the list of files to clean so that multiple threads
won't step over each other during cleanup.
Atomically update wrapperRef in mkWrapperName

It probably helps, and it definitely doesn't hurt.
Don't use unsafeDupablePerformIO in 'panic'

If multiple threads attempt to evaluate a panic at the same time,
more than one exception may be raised.
Make lazyGet thread safe

Evaluating multiple values returned by lazyGet from the same handle
can cause the inner (mutable) offset to be overwritten in between
lazy reads from the Handle, causing invalid results to be returned.
So replace the mutable offset with a fresh MutInt when deferring the
call to getAt.
make FastString thread-safe
Make newUnique and newUniqueSupply use atomic IORef operations
Implement inlinePerformIO correctly
Add the -j flag for parallel compilation
only update mods_done_ref if compilation succeeded
reverse the list of loaded modules like 'upsweep' does
don't assume that the home package is mainPackageId