|
Notes |
|
|
(0019808)
|
|
Bill Hoffman
|
|
2010-03-10 11:47
|
|
|
I think the problem is that you can not incrementally create a shared library like you can with a static one. Everything has to be linked at once. |
|
|
|
(0019810)
|
|
Christoph Höger
|
|
2010-03-10 12:03
|
|
|
In that case I suggest using the @FILE option as an alternative. |
|
|
|
(0019813)
|
|
Brad King
|
|
2010-03-10 13:36
|
|
We support response files with MS tools. The Modules/Platform/*.cmake files activate it on supported platforms using the code
SET(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 1)
SET(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS 1)
I tried setting it for the MinGW generator but got:
C:\mingw\bin\gcc.exe -shared -o libtestc2.dll -Wl,--out-implib,libtestc2.dll.a ... @CMakeFiles\testc2.dir\objects1.rsp ...
gcc.exe: @CMakeFiles\testc2.dir\objects1.rsp: No such file or directory
I tried setting it for the MSYS generator but got:
/C/mingw/bin/gcc.exe -shared -o libtestc2.dll -Wl,--out-implib,libtestc2.dll.a ... @CMakeFiles/testc2.dir/objects1.rsp ...
gcc.exe: @CMakeFiles/testc2.dir/objects1.rsp: No such file or directory
In both cases CMake generates the correct command line and the .rsp file does exist with the correct contents. However the GNU tools do not seem to recognize response file options. I'm using this version:
gcc version 3.4.5 (mingw-vista special)
I see nothing in "gcc --help" or "gcc -v --help" about @ or response files. |
|
|
|
(0019814)
|
|
Christoph Höger
|
|
2010-03-10 14:16
|
|
This is what I get after changing those settings from my MinGW gcc-4.4:
process_begin: CreateProcess(NULL, /C/mingw/bin/g++.exe -shared -o libmosilab_modelica_base.dll -Wl,--out-implib,libmosilab_modelica_base.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/mosilab_modelica_base.dir/objects1.rsp -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32, ...) failed.
make (e=3): The system cannot find the path specified.
It seems to me that the '@' sign must be something special to Windows.
Quoting with "" works fine (except for the fact, that the contents of link.txt are crap for g++ ;)).
So could you add the quotations? |
|
|
|
(0019815)
|
|
Brad King
|
|
2010-03-10 14:34
|
|
On Windows processes are started with the full command line string, not with argv[]. It is up to individual processes to parse the string. Well-behaved processes use a standard parsing function in the language runtime library that then invokes main() with the proper argv[]. The "@" sign is not treated specially by the standard parsing function AFAIK. One of the GNU tools or runtime libraries must be messing with it, although on my system it works (far enough for GCC to look for a file with @ in its name because 3.4.x does not support response files).
Anyway, it shouldn't hurt to always quote the character.
However, we cannot just enable response files on MinGW and MSYS. We need to detect whether the compiler supports them. Does the output of "gcc --help" mention '@'?
What is wrong with link.txt? Are you talking about the response file and called it link.txt by accident? |
|
|
|
(0019832)
|
|
Christoph Höger
|
|
2010-03-11 04:02
|
|
Maybe the @ sign has a special meaning in the shell only (since that was how I tested)?
Regarding link.txt I thought this file would work as a response file. Turns out it does not.
Anyway, to detect the @file option I suggest using the gcc version. 4.x seems to have that option while 3.x does not (even on linux). So gcc --version should help out. |
|
|
|
(0019842)
|
|
Brad King
|
|
2010-03-11 10:02
|
|
|
|
|
(0020963)
|
|
Brad King
|
|
2010-06-10 09:58
|
|
|