hudgens@sun13.SCRI.FSU.EDU (Jim Hudgens) (04/30/91)
This is on a Decstation 5000, Ultrix 4.1, f77 == U4V2.0p.
Anyone ever seen anything like this??? A GKS window appears,
and then the dbx drops out with the "I/O possible" message. Anyone
know what might be causing this?
(dbx2.1) run
[[[[ lots of messages ]]]
I/O possible [select.select:18 +0x8,0x9bfcf8]
Source not available
(dbx2.1) where
> 0 select.select(0x17, 0x113cf9a0, 0x3f, 0x7fffa5e0, 0x7fffa614) ["../select.s
":18, 0x9bfcf8]
1 napms(0x80069, 0x0, 0x113e9b0c, 0x0, 0x113e9ccc) ["../naps.c":84, 0xa095e4]
2 gks$$create_pipes(0x8d6620, 0x113de0c0, 0x2d, 0x1012d3c4, 0x8d6f84) ["handl
er_socket.c":346, 0x8f97d8]
3 gks$$decw_create_sockets(0x113d8654, 0x7fffa82c, 0x7fffa72c, 0x400, 0x7fffa
a80) ["decw_ultrix_input.c":1457, 0x8daaa4]
4 gks$$decw_open_workstation(0x113d8654, 0x113d8fd0, 0x7fffb018, 0x7fffadf0,
0x7fffadec) ["decw_control.c":444, 0x85a3e8]
5 gks3d$$wsm_open_workstation(0x7fffb188, 0x113c3520, 0x7fffb190, 0x10179d24,
0x100cb91c) ["wsm_control.c":342, 0x7ffc20]
6 gks3d$open_ws(0x113c3520, 0x113cfbd8, 0x49004e4f, 0x55444956, 0x4c41) ["knl
_control.c":880, 0x78bb84]
7 gopwk_(0x75d820, 0x112c30bc, 0x0, 0x46, 0x40e27c) ["fb_control.c":299, 0x77
3c50]
[[[ and so on, back up 16 levels ]]]
(dbx2.1) quit
--------------------------------------------------------------
Also, someone else here reported getting the linker message, while
attempting to compile a very large fortran program (i.e. lots of
libraries, GKS, and source code).
---
gks3d$$wiss_wft: both a large and small symbol (possible gp relocation
errors may result)
... lots of the above
ld:
gp relocation out-of-range errors have occurred and bad object file produced (corrective action must be taken)
Best -G num value to compile all -count'd objects creating sdcsim is 4
Above best -G num value conservative because of inconsistent common
symbol sizes. Use the -y flag to trace inconsistant common
definitions and then change source to make them consistent
Best -G num calue calculation reliable only if all
-count'ed bjects were compiled with -G num greater or equal
to maximum size of a literal pool item (8).
---
Translation? Looking at the man page for f77, it appears that the
ld's -G option deals with .comm directives and the "global pointer
register". Apparently this program runs fine on a VAX. Does anyone
know what this might refer to in terms of fortran constructs?
Common block sizes differing?
Thanks for any help...
JHH
--
Jim Hudgens Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edu
"Nothing's for sure except DEC and VAXe .. er, death and taxes"mos@fys.ruu.nl (Henk Mos) (05/02/91)
In <HUDGENS.91Apr29142057@sun13.sun13.SCRI.FSU.EDU> hudgens@sun13.SCRI.FSU.EDU (Jim Hudgens) writes: >This is on a Decstation 5000, Ultrix 4.1, f77 == U4V2.0p. >Anyone ever seen anything like this??? A GKS window appears, >and then the dbx drops out with the "I/O possible" message. Anyone >know what might be causing this? We have the same problems with 2.0. After creating a window (GKS3D) the first line you draw will not show up. But there are more serious problems with 2.0. Compiling with -O3 will give a very good speedup because sometimes DO loops will just be skipped! We just received the new 3.0 (2.1 has the same problems) but... Have a look: program test a = 3. b = 2(a) c = 2**3(a) write (6,*) b, c end This will compile (3.0) without any errors and the results are: 3.00000 24.00000 There are memory allocation and floating points problems as well, but they are very difficult to locate. There seems to be an update so we'll see. Henk Mos -- ---------------------------------------------------------------------- Henk J. Mos, Dept of Physics and Astrophysics, Utrecht University The Netherlands. Phone: 31-30-532239 Email: mos@fys.ruu.nl ----------------------------------------------------------------------
grunwald@foobar.colorado.edu (Dirk Grunwald) (05/02/91)
Is anyone at DEC at liberty to say if the RISC OSF/1 based offering will still use the icky MIPS ECOFF object file format, or will they be switching to ROSE, or will there be a choice (i.e. different kernel loaders) or what. Given that the Gnu C compiler V2beta produces code as good as the mips compiler (unless you enable -O4), it would be nice to be able to move away from the crufty MIPS object file format, because it causes no end of problem when you attempt to use e.g., G++ on these beasties. Thanks. I don't think anyone will be able to say, but what the hey, why not try.