- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I was using ifort compiler, but i have seen the message that it will be deprecated, so I'm trying to use ifx instead, but I get this error:
lld-link: error: section larger than 4 GiB: .data
Do you have any suggestions?
Best regards,
Julie
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This may be an issue previously addressed by @Steve_Lionel
The .data segment is an appendable segment as used by the linker, where each object file's static variables (global or local, iow module, common, and procedure, are appended to the .data section.
Should (many of) your source files contain:
include "someOtherFile.**bleep**"
or
#include "someOtherFile.**bleep**"
.AND.
Those files contain variables that are initialized
Then each instance of those INCLUDEs may (emphasis added) cause the data to be appended to the .data section.
As to if this is a linker bug or not, this would be for others to decide.
Steve's recommendation was to place those data items in a module and then replace the INCLUDE with a USE TheModuleYouMade.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmm, the forum is editing my post (changed triple x to **bleep**)
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK - I believe I may have fixed it using the above reply and some hints found in this thread as well: Re: Huge .bss section size difference with IFX vs IFORT? - Intel Community
When we transitioned from include files to modules, we kept much of the syntax the same. And even worse....kept the common declarations inside the module, even though they were not necessary. I have commented out all the common statements in our biggest module and got everything to link correctly. Now to test results.
I'll post more once I conduct further testing of the built dll, and thanks to everyone for responding quickly to my questions.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>And even worse....kept the common declarations inside the module, even though they were not necessary. I have commented out all the common statements in our biggest module and got everything to link correctly.
This has me suspicious that the compiler generated header file for the module, as opposed to the .mod file, is containing the data from the COMMON. Resulting in each procedure USEing the module (and thus incorporating the header) will add to the .data section.
IMHO this is a bug....
However, should the COMMON be named, then the named common cannot be located in the module .data section as it would be name-mangled (prefexed) with the module name.
IMHO a warning should be issued as to the consequences of using a named COMMON block within a module.
Jim

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »