Sun f90 versions 1.x, included up to Workshop 4, produced .M module
files. f90 versions 2.x, starting in Workshop 5, produce .mod. The
compilers do not produce compatible output, so trying to use a program
compiled with 2.x that uses libraries compiled with 1.x can get these
error messages.
When I made this transition, I recompiled all my own libraries, relinked
LAPACK routines from Sun's newer version of their performance library,
and had to wait for version 3.0 of IMSL, because everything I used had
to be compiled with the new compiler. (If Sun had a simpler way, I
didn't hear about it.)
In other words, you have a Sun f90 version problem, nothing to do with
standards, nor, most likely, with the versions of the hardware you're
running on.
Brian Hanson
On Wed, 8 Nov 2000, Y.K. ZHOU wrote:
=>My questions may seem naive to some gurus, but hope
=>some of you can show me the reasons.
=>Thanks in advance.
=>
=>---------
=>I observed in a:
=>Generic_105181-21 sun4u sparc SUNW,Ultra-2
=>workstation, module subroutine is compiled into
=>.mod file, while in a:
=>Generic_105181-21 sun4u sparc SUNW,Ultra-60
=>workstation, module is compiled into .M file
=>
=>So what's the difference between .mod and .M ?
=>What determines the file extension, is it the
=>hardware?
=>is there anything to do with the compiler?
=>
=>-------
=>One weird thing I encountered is:
=>I compiled same programs in two workstations,
=>for the one with .M extension, my programs work
=>well and the results are right,
=>but for the one with .mod extension, I got SEGV,
=>the dbx info read like:
=>
=>(dbx 3) run
=>Running: run
=>(process id 4130)
=>Enabling Error Checking... done
=> input integers: n, m, p
=>300 1 2
=> your inputs: n= 300 m= 1 p= 2
=>signal SEGV (access to address exceeded protections)
=>in dgeesx_ at 0x6dc45818
=>0x6dc45818: dgeesx_+0x0a60: st %g0, [%g3]
=>
=>(dbx 4) where
=>=>[1] dgeesx_(0x679f38, 0x4335c, 0x0, 0x1, 0x67a8e0,
=>0x1), at 0x6dc45818
=> [2] dschur_factor_(0xfa5d8, 0x12b, 0x1aa2a0, 0x960,
=>0x960, 0x960), at 0x1579c
=> [3] balance_trunc_(0x4381c, 0x960, 0xf9c50, 0x12c,
=>0x10, 0x4383c), at 0x215d0
=> [4] MAIN_(0x12d, 0x436cc, 0x12c, 0x2, 0x3,
=>0x5c118d28), at 0x24a80
=> [5] main(0x1, 0xeffffbc4, 0xeffffbcc, 0x42c00, 0x0,
=>0x0), at 0x20dd0
=>
=>-------
=>
=>How to interpretate and exploit the following info:
=>=>[1] dgeesx_(0x679f38, 0x4335c, 0x0, 0x1, 0x67a8e0,
=>0x1), at 0x6dc45818 ??
=>
=>Here dgeesx is a driver routine (in LAPACK)
=>which can solve standard and generalized
=>nonsymetric eigenvalue problems.
=>
=>I am quite sure the way I called dgeesx was correct,
=>(I assigned enough spaces for the working arrays of
=>dgeesx), the problem is I can't trace into "dgeesx"
=>since it comes from the the sun performance libary
=>(link option: "-xlic_lib=sunperf")
=>
=>Does anyone have some insight what could possibly
=>be the problem? Thanks again.
=>
=>__________________________________________________
=>Do You Yahoo!?
=>Thousands of Stores. Millions of Products. All in one Place.
=>http://shopping.yahoo.com/
=>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|