The .drective section only appears in OBJ files. It contains text representations of commands for the linker. For example, in any OBJ I compile with the Microsoft compiler, the following strings appear in the .drectve section...

This is with Microsoft compilers. Presumably, MinGW or something is doing this now too? Some searching suggests ld generally doesn't understand the directives placed in .drectve, although maybe something changed or it puts something else there.

It's probably just best to ignore the section (a simple fix); I'll try to get GCC 4.8 on my Windows build machine and reproduce it.

In my case I manually modified GHC directory layout so that "mingw" points to recent mingw installation. It contained GCC 4.7. It's important if one wants to use C++ libraries built with more recent GCC.

As far as I know one can't mix code built with different GCC major versions so forcing use of GCC 4.5 isn't exactly the solution.

Perhaps then we should simply upgrade the GCC release included in ghc-tarballs. I'm not sure if I will get to this before 7.8.1 (there's some cleanup on top of the fix for this that's needed,) although tenatively we can try.

We should probably just ignore section names that we don't understand. I think the linker is just being extra paranoid in making sure it understands the whole contents of the object file, but this breaks with pretty much every new gcc/binutils.

rts/linker: ignore unknown PE sections
Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed.
Test Plan:
See the file `ghcilinkerbug.zip` in #9907.
1) unzip file content.
2) open examplecpp.cabal and change base <4.8 to <4.9.
3) execute cabal file with cabal repl.
Applying the patch makes `cabal repl` in step 3) work.
Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99.
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D671
GHC Trac Issues: #9907, #7103, #10051, #7056, #8546