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

[Bill Somerville]

On 01/12/2014 18:55, Brad King wrote:
Hi Brad,

thanks for the quick response on this one.
> 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.
Ran with last nights snapshot dev binary build and it all seems to be 
fine now.

I did have to fix a Qt cmake file error where COPY_ONLY rather than 
COPYONLY was used in a configure_file() command, this will probably hit 
quite a few users. I hope the qt-project.org team have been given a 
heads up on this tightening up of arguments.
>
>> 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.
This also looks good in the log now.
>
> Thanks,
> -Brad
>
Thanks
Bill SOmerville.