lld-link: error: section larger than 4 GiB

[JulieMarieC]

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

[jimdempseyatthecove]

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

[jimdempseyatthecove]

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

Jim

[JohnDrohan]

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

[jimdempseyatthecove]

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