Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29274 Discussions

lld-link: error: section larger than 4 GiB

JulieMarieC
Novice
11,978 Views

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

Labels (2)
0 Kudos
24 Replies
jimdempseyatthecove
Honored Contributor III
5,636 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
5,376 Views

Hmm, the forum is editing my post (changed triple x to **bleep**)

Jim

0 Kudos
JohnDrohan
Novice
4,435 Views

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

0 Kudos
jimdempseyatthecove
Honored Contributor III
747 Views

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

0 Kudos
Reply