link-error, can't get an exe-file

[Eberhard Heuser]

I cannot build a big program with many fortran- and c-subroutines.

The linker reports and exits:

%ILINK-E-IMEXP0, generated image, at least a short data segment, exceeds the P0 address space

Any advice how to get the exe-file?

Eberhard

[Jan van den Ende]

Eberhard,

Hardware, software version, patch level?

Proost.

Have one on me.

jpe

[Eberhard Heuser]

OpenVMS V8.3-1H1
HP Fortran V8.2-104939-50H96
HP C V7.3-018 on OpenVMS IA64 V8.3-1H1

eberhard

[Hein van den Heuvel]

Maybe the targeted image will really be too big, maybe it is an aberration.

May we assume you used to be able to build it?
Can you still build it using prior versions?
Does it generate a map when requested?
Study it! Many little things being rounded up to pages?

If need be you'll have to study the map and see whether the prior version were 'close' to the edge (3fffffff), and a little bit more caused a problem or whether a new module cause a major impact.
New code with large STATIC / COMMON data added? Maybe that data has to go to P2 space somehow?

I hazard to guess that you may have to start playing with linker options like CLUSTER and COLLECT to group stuff.

Hope this helps some.
HB to the rescue (once we know more!)

Hein

[H.Becker]

The linker simply reports that after collecting all the modules and their sections, the generated image does not fit into the P0 address space.

It's not easy to give a general advice. You may get away with some tweaking in linker options and qualifiers. That works if the generated image just needs a couple of pages. But it doesn't say much about running the image, where you may run into problems with allocating heap. You may need to move some image segments out of P0.

Have a look at the /segment qualifier, try to use a smaller /bpage value, try to avoid clusters, try to minimize the generation of image segments.

[GuentherF]

If this is the first time it is linked on Itanium this might be caused by Itanium machine code taking up more space than Alpha code.

Find some larger data psects that can be dynamically created in P2 space ... with some code changes,

/Guenther

[John McL]

Some thoughts ...

How many fortran and c-subroutines? How large are your arrays and do you use multiple separate arrays when you could use one or two global arrays? Will you always use all of the data structures or can you dynamically allocate memory when you need it?

Will you always be calling all routines? If not then maybe split some out into multiple shareable images. Note that I say "multiple", that's because if you had just two you would start running with one and then dynamically activate the second, leaving you probably in a similar position to now.

[H.Becker]

>>> ... or can you dynamically allocate memory when you need it?
<<<
Lookss like a code change. And, I suspect this will only help if the memory is dynamically allocated in non-P0 space.

>>> Note that I say "multiple", that's because if you had just two you would start running with one and then dynamically activate the second, leaving you probably in a similar position to now.
<<<
Even just one can work if you move it to non-P0 space. And, shareable images are compressed, so using them can save some pages in the same way as I suggested before.

[Eberhard Heuser]

This is a little summary. Thanks for all comments!

It turns out that large arrays produce this error. In order to move them to the 64bit address space you have to add directives:

CDEC$ ATTRIBUTES ADDRESS64::x
real*8 x(20000,20000)

If learnt that it is very easy to move common blocks by the method mentioned above:

CDEC$ ATTRIBUTES ADDRESS64::xcom
real*8 x
common /xcom/ x(20000,20000),y(200000)

There is no need to define x and y in the 64 bit address space in the directives.

eberhard

[Eberhard Heuser]

I'll close this thread now!