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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
