Re: Relocation truncated to fit: continued!


Tim Prince wrote:
Steven G. Kargl wrote:
In article <1155008293.253451.277050@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Wong Yung" <wongyung_peach@xxxxxxxxx> writes:
So it seems that the mkl libraries are not compiled with the large or
medium memory profile options.
It's not supposed to matter whether MKL is built with small or medium
memory model, as it doesn't contain large static data regions. I don't
think anyone would like large model, if it made any difference.

I don't think it matters for MKL itself whether the memory model is
small, medium or large. However the problem is,

- the program calls mkl
- part of the program (not dealing with mkl BTW) has massive static
data regions.
- therefore I need to use the large memory model flag when compiling
the program
- the ifort compiler seems to take exception to linking the program to
any libraries which are not also compiled with the same memory model.

The last part seems to be the crux of the problem. I'm only guessing
here. However, the compiler complains about "relocation truncated to
fit etc." about other libraries I am trying to link the program to, not
just mkl, and these error messages disappear once I recompile said
other libraries with the large memory model so it seems logical that
this is the problem with mkl and its "relocation truncated to fit"
errors.

The part of the program that requires mkl is only a relatively small
bit of the program so my current workaround (after tearing my hair out
about compiler options) is to seperate this part from the main program
as an independent program (loading in the required data from the output
of the 1st program), compile the first program with it and every other
library linking to it with the large memory model and compiling the
second program (the one requiring mkl) with the small memory model and
everything seems to work OK then. However, it seems a bit awkward and
nasty.


There have been revisions in ifort IA-64 to make make ld work in some
cases where it was failing, but this doesn't appear to cover many cases.
As you don't care to tell us whether you ever revealed your binutils
version (e.g. ld --version), I'll remind you that this is likely a
binutils problem.
Since you don't think it worth while to give us a reference to the
newsgroup archives, I won't second guess you, but I'll agree with your
remarks about inadequacy of google newsgroups.

I have no idea what I did to deserve your little remark here as I did
provide a link to the original thread in my OP for this thread.

My binutils version is:

GNU ld version 2.15.94.0.2.2 20041220 (SuSE Linux)

BTW, I am using Opterons not Itaniums so unfortunately (fortunately?)
nothing about IA-64 applies to me.



If I haven't already issued enough advice about not expecting
professional support on multi-vendor issues, without a special contract,
consider that I don't speak for my employer or any other software
vendor. Take advantage of the work others are doing on FSF software.

Look, I have no idea where you get the idea I am interested in
professional support from. When have I ever indicated that? I am
using the free version of Intel's compiler. Given it's free I'm not
going to expect Intel to bend over backward to help me if I run into
problems. Which by the way is why I'm here instead of phoning up Intel
and harassing their employees :)

.

Relevant Pages

  • Re: C#, Threads, Events, and DataGrids/DataSets
    ... Jon asked me to weigh in on the memory model issue below. ... there is enough wiggle room in the spec to cause grief. ... so the JIT compiler can know special things about it). ... memory cell will be access cross thread without synchronization). ...
    (microsoft.public.dotnet.general)
  • Re: And now my thoughts on Delphis survival
    ... others had to jump out of the Pascal linage during the Turbo Pascal ... days for lack of additional memory model support. ... I don't know exactly what you mean by large or huge (since that is compiler ... engineer student in that time) has totally disappeared, ...
    (borland.public.delphi.non-technical)
  • Re: Problem with realloc (I think)
    ... If Borland C++ 5.x is a 16 bit compiler, ... and depending on your memory model you won't be able ... The parameter to malloc is a size_t type, not an int. ...
    (comp.lang.c)
  • Re: equivalent to far in linux/unix
    ... FAR and HUGE have to do with the memory model of DOS ... These modifiers then told the compiler "the address is stored ... they just operate on a gigantic flat array ...
    (comp.unix.programmer)