View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010401CMakeCMakepublic2010-03-10 11:322010-06-10 09:58
ReporterChristoph Höger 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010401: Cannot build dll's with MinGW due to 32k limit
DescriptionThe variable archiveCommandLimit in cmMakefileLibraryTargetGenerator.cxx is used to generate static libraries even if there is an issue with the 32k limit under windows.

Unfortunately this variable is not applied when building shared libraries only.
I have a library here that consists of more then 700 (generated) code files and cannot build it as a dll with MinGW because of the"The parameter is incorrect" error.

I'd suggest setting the archiveCommandLimit to 30k by default wether or not there is a static library being build.
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0019808)
Bill Hoffman (manager)
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 (reporter)
2010-03-10 12:03

 In that case I suggest using the @FILE option as an alternative.
(0019813)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
2010-03-11 10:02

 I discovered that gcc 3.x does support the @ option in its linker backend (collect2). Using "-Wl,@" works.

I pushed out a branch to gitorious.org to try:

http://gitorious.org/~bradking/cmake/cmake-sandbox/commits/response [^]
http://gitorious.org/~bradking/cmake/cmake-sandbox/commit/87f0853 [^]
http://gitorious.org/~bradking/cmake/cmake-sandbox/commit/f9268c9 [^]
http://gitorious.org/~bradking/cmake/cmake-sandbox/commit/00477de [^]
(0020963)
Brad King (manager)
2010-06-10 09:58

 I've merged the topic into 'next':

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b998508e [^]

 Issue History
Date Modified Username Field Change
2010-03-10 11:32 Christoph Höger New Issue
2010-03-10 11:47 Bill Hoffman Note Added: 0019808
2010-03-10 11:47 Bill Hoffman Status new => assigned
2010-03-10 11:47 Bill Hoffman Assigned To => Bill Hoffman
2010-03-10 12:03 Christoph Höger Note Added: 0019810
2010-03-10 13:36 Brad King Note Added: 0019813
2010-03-10 14:16 Christoph Höger Note Added: 0019814
2010-03-10 14:34 Brad King Note Added: 0019815
2010-03-11 04:02 Christoph Höger Note Added: 0019832
2010-03-11 09:48 Brad King Assigned To Bill Hoffman => Brad King
2010-03-11 10:02 Brad King Note Added: 0019842
2010-06-10 09:58 Brad King Note Added: 0020963
2010-06-10 09:58 Brad King Status assigned => closed
2010-06-10 09:58 Brad King Resolution open => fixed

Copyright © 2000 - 2018 MantisBT Team