"make check" may have trashed my system

[Paul J. Menchini]

Hello,

Per the instructions in .../autoconf-2.50/README, I tried to send the
message below to address@hidden, but received the following
errors:

>    ----- The following addresses had permanent fatal errors -----
> address@hidden
>     (reason: 550 Unknown local part autoconf-bugs in <address@hidden>)

>    ----- Transcript of session follows -----
> ... while talking to fencepost.gnu.org.:
>>>> DATA
> <<< 550 Unknown local part autoconf-bugs in <address@hidden>
> 550 5.1.1 address@hidden User unknown
> <<< 503 Valid RCPT TO <recipient> must precede DATA

Here is the original message:


From: "Paul J. Menchini" <mench>
Subject: "make check" may have trashed my system
To: address@hidden
Date: Fri, 20 Jul 2001 12:32:56 -0400 (EDT)
Cc: mench (Paul J. Menchini)

Hello,

I am attempting to install autoconf 2.50, found at
ftp://ftp.duke/edu/pub/gnu/autoconf, on two machines I maintain:

1.  a Sparc IPC running SunOS 4.1.3, and

2.  a Sun5 running Solaris 2.5.1.

This report concerns the first machine, as the installation on the
second has gone ok (to the point of the "make check").

Because I'm building autoconf (and other Gnu tools) for two different
architectures, my methodology has been as follows.  (Bash is the shell
used on both machines, and Gnu make 3.79.1 and GNU m4 1.4 are used on
both machines.)

On SunOS:

        % cd .../autoconf-2.50
        % mkdir obj.sunos4
        % cd obj.sunos4
        % ../configure > configure.log 2>&1 & sleep 1;tail -f configure.log
        % make > make.log 2>&1 & sleep 1;tail -f make.log
        % make check > check.log 2>&1 & sleep 1;tail -f check.log
        % make install > install.log 2>&1 & sleep 1;tail -f install.log

The Solaris build methodology is the same, except the directory obj.sunos5
is used instead of obj.sunos4.

My problem on SunOS occurred during the "make check."  Here is a portion
of the file .../obj.sunos4/check.log:

                :
                :
        make[2]: Entering directory 
`/dat00/usr/local/src/autoconf/autoconf-2.50/obj.sunos4/tests'
        /usr/local/bin/m4 -I ../../tests -I ../.. atspecific.m4 suite.at | \
                  sed -e 's/[   ]*$//' | \
          sed -e '/^$/N;/\n$/D' >testsuite.tmp
        chmod +x testsuite.tmp
        mv testsuite.tmp testsuite
        /bin/sh testsuite
        ================================
        Test suite for GNU Autoconf 2.50
        ================================
 
        Some tests might be skipped if you don't have the software which the
        macros check (e.g., a Fortran compiler).
 
 
        Executables (autoheader, autoupdate...).
 
          1: tools.at:29       ok (skipped near `tools.at:53')
          2: tools.at:76       ok (skipped near `tools.at:82')
          3: tools.at:108      ok
          4: tools.at:168      ok
          5: tools.at:201      FAILED near `tools.at:225'
          6: tools.at:232      FAILED near `tools.at:267'
          7: tools.at:279      FAILED near `tools.at:313'
          8: tools.at:327      ok
          9: tools.at:413      ok (skipped near `tools.at:434')
        testsuite: false: not found
         10: tools.at:447      testsuite: /tmp/sh2718822: No such file or 
directory
        testsuite: /tmp/sh2718823: No such file or directory
        testsuite: /tmp/sh2718824: No such file or directory
        ok (skipped near `tools.at:461')
        testsuite: false: not found
                :
                :


At this point, a number of other things started to go wrong on my
system.  I immediately discovered that /tmp (a symbolic link) was gone.

After a bit more digging, I discovered that every non-directory file in
/ was gone; in particular, the symbolic links /bin, /lib, and /sys (in
addition to /tmp and some local symbolic links) and the files /boot,
/kadb and /vmunix (as well as some backup versions of /vmunix) were
gone.  In addition, my bootblocks on / were trashed.

I have managed to restore the system to its previous state, and I would
like to continue with the installation of autoconf.  However, I don't
wish to have a repeat of the above problems.

Can you suggest anything with autoconfig's make check that might have
caused this problem?  In looking quickly for various other potential
problems, I can find none.

Thanks for your assistance, and please let me know if I can provide any
further information.

Regards,

Paul

--
Paul Menchini         | "There must have been a time, probably somewhere near
Menchini & Associates |  the beginning, when we could have said 'no.'"
www.mench.com         |         -- from "Rosencrantz and Guildenstern are Dead"