Relocation truncated to fit: continued!
in [Fortran]
|
From: Wong Yung on 7 Aug 2006 23:38 Resurrecting an old thread with new developments. The old thread can be seen here: http://groups.google.com.au/group/comp.lang.fortran/browse_frm/thread/c8b059759e5e1290/582ea81333d858d9?lnk=st&q=&rnum=1&hl=en#582ea81333d858d9 Unfortunately I can't just continue that thread because it is more than 30 days old or closed by the moderator according to google...so I'll have to start a new thread. OK, from the compiler output as seen on the 1st post, it clearly looks like the problem is with ARPACK. I recompiled arpack with "-mcmodel=large -i-dynamic" and voila the compiler errors related to arpack disappeared...to be replaced by the same "relocation truncated to fit" messages for mkl: /opt/intel/mkl721/lib/em64t/libmkl_lapack.a(zhetrd_omp.o)(.text+0xebf): In function `_mkl_lapack_zhetrd_347__par_region2': ker_zhetrd_omp.f: relocation truncated to fit: R_X86_64_PC32 against `.bss' /opt/intel/mkl721/lib/em64t/libmkl_lapack.a(zhetrd_omp.o)(.text+0x11d0):ker_zhetrd_omp.f: relocation truncated to fit: R_X86_64_PC32 against `.bss' So it seems that the mkl libraries are not compiled with the large or medium memory profile options. Unfortunately, unlike arpack I can't exactly recompile the intel mkl libraries myself. So does anyone have any ideas on what I can do?
From: Steven G. Kargl on 8 Aug 2006 00:05 In article <1155008293.253451.277050(a)m73g2000cwd.googlegroups.com>, "Wong Yung" <wongyung_peach(a)yahoo.com> writes: > > So it seems that the mkl libraries are not compiled with the large or > medium memory profile options. Unfortunately, unlike arpack I can't > exactly recompile the intel mkl libraries myself. > > So does anyone have any ideas on what I can do? Contact Intel? Install a different compiler? -- Steve http://troutmask.apl.washington.edu/~kargl/
From: Reinhold Bader on 8 Aug 2006 06:59 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wong Yung wrote: [elided unnecessary parts] > "relocation truncated > to fit" messages for mkl: > > /opt/intel/mkl721/lib/em64t/libmkl_lapack.a(zhetrd_omp.o)(.text+0xebf): > In function `_mkl_lapack_zhetrd_347__par_region2': > ker_zhetrd_omp.f: relocation truncated to fit: R_X86_64_PC32 against > `.bss' > /opt/intel/mkl721/lib/em64t/libmkl_lapack.a(zhetrd_omp.o)(.text+0x11d0):ker_zhetrd_omp.f: > relocation truncated to fit: R_X86_64_PC32 against `.bss' > > So it seems that the mkl libraries are not compiled with the large or > medium memory profile options. Unfortunately, unlike arpack I can't > exactly recompile the intel mkl libraries myself. > > So does anyone have any ideas on what I can do? > Note that the version of MKL you are linking is quite old; I suspect newer releases (8.1 is current) might provide a fix for this problem. Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2G6vFVLhKuD7VgsRAvqSAJ40ZYiZ6cVsOCh7aAunfCj5Psz/DQCfa54Z GS9DaDOybBT8C3GtNO0BzPU= =BI1q -----END PGP SIGNATURE-----
From: Tim Prince on 8 Aug 2006 21:06 Steven G. Kargl wrote: > In article <1155008293.253451.277050(a)m73g2000cwd.googlegroups.com>, > "Wong Yung" <wongyung_peach(a)yahoo.com> 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. >> So does anyone have any ideas on what I can do? > > Contact Intel? If you can prove (possibly using netlib source) that you have a case where you need MKL built with a different memory model. > Install a different compiler? > 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. Note that gfortran and Intel compilers for linux all depend on the binutils you provide (or inherited from your linux distro). I've found failures in RH EL4 (including inability to build libstdc++ with either g++ or icpc). I had success for both IA-64 and x86-64 versions by installing the current source versions of binutils from ftp.kernel.org. There is a hot fix from Red Hat for the IA-64 binutils (not as good as current binutils), without which several Fortran MPI programs fail with such an error, but I don't believe the working one comes with a packaged distro. Neither gfortran nor ifort, on any platform of which I am aware, provide the library and link tools, so you can't expect the compiler to take care of such problems. Getting fixes (even "hotfix") for the big name distros takes the better part of a year, and it won't help you with the current broken stuff. Yes, MKL is intended to work with compilers other than ifort (with possible exceptions where ifort WRITE error messages are compiled into LAPACK). So you are more than welcome to try it with gfortran et al. "it worked for 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.
From: Wong Yung on 11 Aug 2006 04:26
Tim Prince wrote: > Steven G. Kargl wrote: > > In article <1155008293.253451.277050(a)m73g2000cwd.googlegroups.com>, > > "Wong Yung" <wongyung_peach(a)yahoo.com> 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 :) |