jpc@iesd.uucp (Jens P. Christensen) (12/06/87)
Could anyone please shed light on a problem I have in compiling the S statistical package from AT&T on our Sun-3 system: System specifics: Sun 3/260 under SunOS 3.4 using the m4 macro processor supplied with the S system. S version date: Fri Feb 28 1986 Using the hints on compiling with BSD4.2 systems I only get apparently harmless warnings under the compilation. This could for example be: Warning on line 84 of hcp.f: local variable i never used Warning on line 96 of stems.f: statement cannot be reached f77: Warning: File with unknown suffix (/usr/local/src/s/S/newfun/lib/grz) passed to ld or "dprint.c", line 20: warning: illegal combination of pointer and integer, op = Furthermore there are problems with the utility routine scandata.C, which fails with error: too many local variables. This is fixed by making the declaration of "table" global. Not pretty, but it works. These are all the kinds of problems that appear during the compilation, and it *will* result in an executable, except.... The f...ing system doesn't even know how to add two numbers, as seen in the following: One-time initialization for new S user in /usr.MC68020/iesd/tap/jpc ... Directories swork and sdata created > 1 + 2 Bad operator: + Error in + > Running the tests supplied with the system ($A/DOTEST ALL) will not give better results. This is an excerpt from $TEST/current/apply: > prefix("apply.") # test of apply and multivariate stuff, some time-series > $Random.seed_c(57,0,3,0,0,0,49,16,0,0,0,0) # to initialize at same spot > matr_matrix(rnorm(100),20,5) Invalid distribution: rnorm Error in rnorm Dumped > print(cm_apply(matr,2,"mean")); apply(matr,2,"var") apply.matr not found Dumped . . and more depressing errors... Why does the prefix command work, while the matr_matrix(rnorm... stuff don't? So, have *anybody* made this run on a Sun system, and how did you do it? All suggestions or pointers to which direction I should go, are welcome. regards, -- Jens Peter Christensen jpc@iesd.uucp Department of Math. and Computer Science {...}!mcvax!diku!iesd!jpc Aalborg University Centre Denmark
rab@alice.UUCP (12/16/87)
In article <162@iesd.uucp>, jpc@iesd.UUCP writes: > Could anyone please shed light on a problem I have in compiling the S > statistical package from AT&T on our Sun-3 system: > > System specifics: Sun 3/260 under SunOS 3.4 using the m4 macro > processor supplied with the S system. S version date: Fri Feb 28 1986 > > > 1 + 2 > Bad operator: + > Error in + > > So, have *anybody* made this run on a Sun system, and how did you do it? You have stumbled across a bug in the f77 compiler in Sun's 3.4 release. Others have gotten around the problem by re-installing f77 from the 3.2 release. Sun says they will fix the problem soon -- you might want to check with them. Here is the bug report that I sent to Sun: __________________________________________________ On pg 89 of Release 3.4 Manual for the Sun Workstation, Part 800-1614-10, Revision A of 14 May, 1987, listed under "incorrect handling of Backslash characters" is the following: Previously, f77 did not correctly handle the backslash character (\). It converted a double backslash (\\) to a single backslash, requiring you to type four backslashes (\\\\) for a double backslash. The compiler converted \0 to the ASCII character 0, which is the string terminator for C, rather than FORTRAN. THis has been fixed in Release 3.4. Whoever "fixed" this bug should read page 89 of the Fortran Programmer's Guide, Part 800-1371-02, Revision E of 17 February, 1986. It states: For compatibility with C usage, the following backslash escapes are recognized: and then has Table 6-1 that shows backslash escape sequences including \\ and \0. These escapes are extremely important to Fortran programmers that are communicating with C. For example, they are the only way to get null-bytes into character strings that are initialized by data statements. Here's a simple example: character *100 foo data foo/"this is a test string\0"/ call bar(foo) stop end Here is the C function bar: bar_(s,l) char *s; long l; { printf("The string is: %s\n",s); printf("its actual length is %ld but its declared length is %ld\n", strlen(s),l); } Here's the result on a Sun OS 3.2 system. $ f77 foo.f bar.c foo.f: foo.f: MAIN: bar.c: Linking: $ a.out The string is: this is a test string its actual length is 21 but its declared length is 100 Here's the result on a Sun OS 3.4 system. $ f77 foo.f bar.c foo.f: foo.f: MAIN: bar.c: Linking: $ a.out The string is: this is a test string The string is: %s its actual length is 118 but its declared length is 100 -- Rick Becker alice!rab research!rab
smiller@umn-cs.cs.umn.edu (Steven M. Miller) (12/16/87)
In article <162@iesd.uucp>, jpc@iesd.uucp (Jens P. Christensen) writes: > Could anyone please shed light on a problem I have in compiling the S > statistical package from AT&T on our Sun-3 system: > There is a known problem that you could be running into. in ~Ssourcedir/src/main/main.C you need to add a call to f_init() I may have the above line slightly incorrect, as I no longer am working at a site with S and the above is from memory. Also in Sun 3.2 there was an Optimizer bug that came up, but Sun probably has it fixed in 3.4. The guru's at AT&T (rick@alice.uucp) can probably help out too. -- -Steve Miller, U of MN