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.
--
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
