derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (12/16/89)
Here's another one for netland to think about. I'm doing software development using SR10.1 on a DN4000 with Pascal 8.6 and C 6.6 (application mixes both). Two odd things are happening, one always and the other intermittently. The intermittent problem is that when trying to execute the bound object code, I get a "file is not an object module or is not executable on this machine type" message. I'm using Motorola compilers and running on a Motorola node (actual execution is on a DN3000). I'm in a cycle of minor change-compile-bind-run-repeat, and the problem pops up sometimes and not others for no discernable reason. The other problem is that after I bind the object, the length is 292 blocks, but the "current length" is about 5 MB. After executing the code, the block length increases to about 5000. Moreover, this occurs even when the code does not actually run due to the other problem. A guess I had was that it had something to do with allocating space in the coff file for all the static storage, but I was unable to replicate this behavior with small test programs. Does anyone have explanations for these? The first problem is really the troublesome one; the second is just annoying, and I suspect there is a logical explanation (although I find it hard to understand how executing an object is allowed to change the object.). Thanks in advance, Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com
marmen@is2.bnr.ca (Rob Marmen 1532773) (12/18/89)
In article <8912152124.AA21689@umix.cc.umich.edu>, derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") writes: > > I'm doing software development using SR10.1 on a DN4000 with > Pascal 8.6 and C 6.6 (application mixes both). > > The intermittent problem is that when trying to execute the bound > object code, I get a "file is not an object module or is not executable > on this machine type" message. I'm using Motorola compilers and running > on a Motorola node (actual execution is on a DN3000). I'm in a cycle > of minor change-compile-bind-run-repeat, and the problem pops up sometimes > and not others for no discernable reason. > > Dave Erstad > Honeywell SSEC > DERSTAD@cim-vax.honeywell.com I ran into the same problem at our site. I was trying to execute an Apollo compiled program which had been moved to an HP 9000 for storage. I was accessing the module from the HP via NFS. The problem was reported to the Apollo hotline. I forgot what the response was. We've labelled it an NFS "feature". Hope this helps.... rob... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Robert Marmen marmen@bnr.ca OR | | Bell Northern Research marmen%bnr.ca@cunyvm.cuny.edu | | (613) 763-8244 My opinions are my own, not BNRs |
derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (12/20/89)
From Robert Marmen: > I ran into the same problem at our site. I was trying to execute an Apollo compi > led > program which had been moved to an HP 9000 for storage. I was accessing the modu > le > from the HP via NFS. and Andrew Wescott: > I think you will find the NFS problem is solved with > the above combination. Actually, I think the newest > Pascal compiler will do the job.. The above combo > should also solve the vms problem you were having. > I beta-tested all of the current compilers, and I was > able to compile and link remote (NFS) source files, > as well as load executables onto the NFS disk. However, this is not an NFS problem. Everything is on the same token ring. I have determined that local binds never exhibit this problem, and the object code runs on at least two other nodes successfully, so I suspect my local nodes type managers might be corrupted somehow. It's odd that the problem is intermittent, however. We may reload my node. I'll keep the net posted. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com
ALBRECHT@INTELLICORP.COM (Steve Albrecht) (12/20/89)
RE: "file is not an object module or is not executable on this machine type" I assume that the target DN3000 is also running SR10.1. If it is running SR9.7 or before, than you will have to convert the COFF object file. Speaking from knowledge of the Domain and UNIX C compilers only, the deafult target should be "any", but you may want to specify it explicitely with the -cpu or -M options. See pp 6-222 and 6-23 of Domain C Language Reference for details. RE: "block length increases to about 5000" Do you mean "the file length increases to about 5000"? If so, this is a well known problem in SR10.1 for which a fix is promised in SR10.2. Grit your teeth if you need it fixed in Domain/OS 10.1. (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) ) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development ( ( "Opinions expressed here are my own, if anyone's, and not my employer's." ) ) DDS albrecht@intellicorp.com : COMPUSERVE 73657,1342 ( ( UUCP ...!sun!intellicorp.com!albrecht : public bbs (415)969-5643 ) ) or ...!sun!icmv!albrecht : "c"omment to sysop ( (::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::) -------