[CMake] 3.1 can't link my MinGW executables any more.

[Brad King]

On 12/01/2014 12:04 PM, Bill Somerville wrote:
> https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.0.2
> https://dl.dropboxusercontent.com/u/4192709/CMakeOutput.log.3.1.0-rc2

The relevant portion of these logs starts in the line

 Detecting Fortran compiler ABI info compiled with the following output:

Below that we see CMake's log of the command it invoked in 3.0:

 C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe  ...

versus 3.1:

 C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe  ... @CMakeFiles\cmTryCompileExec3596737510.dir\linklibs.rsp

The response file will be empty in this case.  This difference comes from
the topic merged here:

 Merge topic 'link-libraries-response-files'
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c9041bd

The next line in both logs is printed by the gfortran tool and is identical:

 Driving: C:\Tools\Qt\Tools\mingw48_32\bin\gfortran.exe -v ... -l gfortran -shared-libgcc

This means the gfortran front-end's invocation of its internal compiler
to do the linking is identical in the two cases.  However, later the logs
show different lines, both starting with

 c:/tools/qt/tools/mingw48_32/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/collect2.exe

In 3.0 it has the form:

 .../collect2.exe ... --whole-archive CMakeFiles\cmTryCompileExec480971319.dir/objects.a
    --no-whole-archive --out-implib libcmTryCompileExec480971319.dll.a
    --major-image-version 0 --minor-image-version 0 -lgfortran ...

and in 3.1 it has the form:

 .../collect2.exe ... @C:\Users\bill\AppData\Local\Temp\cc7mMWSg ...

where the '...' parts are the same in both logs.  Something causes gfortran to
decide to put all those arguments in a response file.  They are hidden from
CMake so the -lgfortran part cannot be extracted.  Somehow using a response
file on the initial command line causes gfortran to use one for its internal
invocation.  This is reasonable behavior because if the original caller had
a long command line then so might the internal invocation.

I've created the following workaround:

 Makefile: Do not create an empty linker response file
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c5be1f3

Please let me know if that works for you.

> One thing that looks suspicious are the lines mapping words to content 
> along the lines of :
> 
>      arg [-lmingw32] ==> lib [mingw32]
>      arg [-lgcc] ==> lib [gcc]
>      arg [-lgcc_eh] ==> lib [gcc_eh]
> 
> which in 3.1 look like this:
> 
>      arg [-lmingw32] ==> lib []
>      arg [-lgcc] ==> lib []
>      arg [-lgcc_eh] ==> lib []
> 
> I'm not sure where they are generated.

That looks like a regression only in construction of the log messages.
I've fixed that here:

 CMakeParseImplicitLinkInfo: Fix implicit library logging
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20bf6971

and will include it in the next 3.1 release candidate.

Thanks,
-Brad