kgallagh@digi.lonestar.org (Kevin Gallagher) (03/26/91)
In article <508110b0.20b6d@apollo.HP.COM> vinoski@apollo.HP.COM (Stephen Vinoski) writes: >A couple of perl 4.0 ANSI C problems on Apollo DN3500 running >Domain/OS sr10.3 and using cc 6.8: > >1) My ANSI C compiler didn't like the fact that "extern char **environ" >was surrounded by "#ifdef __STDC__" in several perl 4.0 source files, >namely > > doarg.c > perl.c > str.c > util.c > >They compiled fine once I removed the #ifdef. Actually, they are surrounded by "ifndef". Otherwise, Stephen Vinoski is correct. Now, for those of us who don't yet have cc 6.8 installed, here's some additional information needed to build perl successfully. If you have been running an SR10.3 node for a while, it is likely that cc 6.8 was not available when SR10.3 was installed. This means you have a re-built SR10.3 version of cc 6.7. This, of course, is the source of a great deal of confusion, because the SR10.3 installation procedure asks if you wish to install ANSI compatibility. The SR10.3 installation notes (buried in section 1.11.5) state that one is supposed to say NO if you have version 6.7 of the compiler and YES if you have version 6.8. Of course, I suspect that MOST SR10.3 installers answered YES, regardless of the cc version they have. They did here on our 10.3 nodes. If you have SR10.3 with cc 6.7 installed, as if it were ANSI compatible, you should make Stephen Vinoski's small source modifications. Then run Configure and take all the defaults. Your subsequent build of Perl should be successful. If you are running SR10.2 you should have cc 6.7. You are no doubt aware that Apollo defines __STDC__ by default in this version of the compiler, EVEN THOUGH cc 6.7 is quite a long way from being ANSI compliant. To build Perl successfully, your MUST undefine __STDC__ by using the -U preprocessor switch to /bin/cc. >2) The declarations for malloc(), free(), and realloc() in malloc.c do >not match the ANSI C function prototypes. I fixed this with #ifdef. When I used the Perl supplied malloc.c, many of the tests in the Perl test suite failed with malloc errors, under both 10.2 and 10.3 built versions. When I rebuilt Perl without Perl's malloc.c, the malloc problems went away. (The malloc supplied with Perl 3.0.44 worked fine in that version. So, something got broke in Perl 4.0. -------------------------------------o---------------------------------------- When running the Perl test suite on an Apollo built version of Perl, there are two tests that sometimes fail and sometimes pass when the tests are repeated over and over again. 1. The bsd4.3 sleep function (don't know about sys5.3) has a known bug where it sometimes returns one second earlier than the total specified time. So, one of the sleep tests will fail, sometimes, and will pass at other times. 2. A newly created empty file on the Apollo will end up, occasionally, with a create time and a modified time that differ a little. This causes one of the stat tests to fail, on occasion. Since we have both SR10.2 and SR10.3 nodes, I had to build a version of Perl which will run on both OS loads. After successfully building and testing Perl on a 10.2 node, I ran the test suite on a 10.3 node. At first I was puzzled. When running the test suite on the 10.2 built version, but from 10.3 node, one of the tests (t/comp/cpp.t) fails; Perl issues the following error message: "Missing source file argument to cpp." In retrospect, this does not surprise me. When running Configure on my 10.2 node, it determined that it could not feed standard standard input to cpp via: cc -E < testcpp.c but it could do so via: cc -E - < testcpp.c However, on the 10.3 node, the latter method also fails. On 10.3, Configure concludes that /bin/lib/cpp < testcpp.c works, but not the other two methods. Why this is different under 10.3 seems strange to me. I had to re-build Perl on my 10.2 node, modifying config.sh to to reflect that /bin/lib/cpp is the proper way to invoke cpp. Now, the big question is "Why did Apollo change this under SR10.3?" It can't be intentional, so I suspect it is a bug. -- ---------------------------------------------------------------------------- Kevin Gallagher kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh DSC Communications Corporation Addr: MS 152, 1000 Coit Rd, Plano, TX 75075 ----------------------------------------------------------------------------