| Anonymous | Login | 2020-04-03 08:17 UTC |  |
| My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0000155 | OMNeT++ | command line tools | public | 2010-04-23 16:21 | 2010-12-09 17:12 | ||||
| Reporter | rhornig | ||||||||
| Assigned To | rhornig | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 4.1b3 | ||||||||
| Target Version | Fixed in Version | 4.2 | |||||||
| Summary | 0000155: Large projects cannot be built on MINGW because of linker command line length limitation | ||||||||
| Description | The INETMANET project cannot be linked if all sources are included in the build (i.e. including the underTest directory). Command line arguments are limited to 32K on windows. It is possible to pass a long command line by putting the commands into a file and pasing the filename as @filename to g++. | ||||||||
| Additional Information | A fix has been implemented which puts the linker command line onto a file and invokes g++ using the @.tmp$$ syntax on windows if we are using minge compiler and it detects larger command line size. Unfortunately g++ extracts all the options from the file and tries to pass the expanded command line when it invokes internally the linker program. So the linker will again fail. It would be a solution if we could convince g++ not to expand the file. There are suggestions to use the -Wl,@filename option to pass all the object files to the linker without expanding it. At the moment it seems that in this case the nternal "collect2" program fails. See: http://www.itk.org/Bug/view.php?id=10401&nbn=5 [^] | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0000241) andras (administrator) 2010-04-23 16:52 |
Possible workaround: keep the @tmpfile fix, and additionally wrap the linker command into a perl script. The perl script could split up the list of object files to 2 or more sub-lists (each <32K), create temporary static libs from each of them, and call the linker to build dll from those static libs. |
|
(0000343) rhornig (administrator) 2010-12-09 12:49 |
The current workaround (using response files i.e. @file) is not working becaose of a bug in mingw'S collect2 executable. See the related discussion on the gcc list. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749 [^] |
|
(0000346) rhornig (administrator) 2010-12-09 17:12 |
Added a preliminary step of building static library first using the @response files syntax. The library tool can handle response files correctly. After this, the created temporary static lib is used in the linker command line. This could be dropped if the @resultfile handling in MINGW/GCC 4.5.1 is fixed and a new version is bundled with omnet. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2010-04-23 16:21 | rhornig | New Issue | |
| 2010-04-23 16:52 | andras | Note Added: 0000241 | |
| 2010-05-06 09:31 | andras | Status | new => confirmed |
| 2010-12-09 12:49 | rhornig | Note Added: 0000343 | |
| 2010-12-09 17:12 | rhornig | Note Added: 0000346 | |
| 2010-12-09 17:12 | rhornig | Status | confirmed => resolved |
| 2010-12-09 17:12 | rhornig | Fixed in Version | => 4.2 |
| 2010-12-09 17:12 | rhornig | Resolution | open => fixed |
| 2010-12-09 17:12 | rhornig | Assigned To | => rhornig |
|
Issue History |
| Copyright © 2000 - 2020 MantisBT Team |
 |