Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1130 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1130.

Report 1130 Actions

    Problem Report Number 1130
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0332
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSU version 4.1.1
    Test Identification CAPIheaders/sys/stat.h 1-8
    Problem Summary PG4U.00140 The submitter contends the makefile for this test is non-portable.
    Problem Text
    The section of the makefile for this can be cut down to this

    hstat7: hstat7.c ${VSU_INCDIR}/hstat.H
    ${VSU_USER_C89} ${VSU_CFLAGS} -o hstat7 hstat7.c ${VSU_LIBS_COM}
    @rm -f *.o

    rmdef:
    @rm -f ${VSU_INCDIR}/hstat.H

    ${VSU_INCDIR}/hstat.H: rmdef
    hdrdefs sys/stat.h ${VSU_SYS_INCLUDES} > ${VSU_INCDIR}/hstat.H
    ${VSU_USER_C89} ${VSU_CFLAGS} -E hstatA.c | hdranal sys/stat.h >>
    ${VSU_
    INCDIR}/hstat.H


    We believe we can simplify the above makefile section to the below to aid
    in explaining the problem.

    The makefile, further simplified, says

    t: t.c inc.h
    "compile t.c using inc.h"

    inc.h: rem
    "create inc.h"

    rem:
    rm inc.h

    If make finds that "inc.h" has the same timestamp as "right now",
    it knows that it is up-to-date. It doesn't know that "rem" will
    remove it away, but "rem" must always be done, as we understand
    make, because it's one of those fake targets that doesn't
    exist in the filesystem. So, suddenly the compile fails because
    inc.h has been removed.

    If make finds that "inc.h" is older than "right now", it figures
    that it should do the "create inc.h" after "rm inc.h" because it
    might matter, since "rem" was done.

    The problem is that the "right now" timestamp is how make marks
    just-built items, and today's machines can easily do a bunch of
    things within the one second granularity of filesystem timestamps.

    We have some suggestions on how to change the makefile to be
    more explicit and these are given below.

    Assuming that the intent was to recreate inc.h anew for each
    invocation, this could be done by saying

    t: t.c new
    "compile t.c using inc.h"

    new:
    rm inc.h
    "create inc.h"

    If inc.h doesn't need to be recreated each time but only when
    it isn't present, this even more straightforward:

    t: t.c inc.h
    "compile t.c using inc.h"

    inc.h:
    "create inc.h"

    Our implementation does not claim support of the DEVELOPMENT option of XCU
    but even if we did we believe we support the description of make as it now
    stands in this matter.

    A support request resulted in the following from the testsuite
    developers.

    > We will consider this enhancement request for inclusion in the next release.
    >
    > However at a technical level this appears to us to be a deficiency in
    > your version of make. We submit two arguments:
    >
    > >From a practical perspective, this technique is a time honored way
    > for makefile programmers to force updates by removing prerequisites.
    > Its commonly used and not accomodating it breaks existing practice.
    > For example, we've run these makefiles on lots of makes on lots of
    > systems, fast and slow, and we've never seem the behavior you describe.
    >
    > >From a logical perspective, a non-existant prerequisite must by
    > definition always be more uptodate than its target. Using your stripped
    > down notation, the rem target is executed because the rem dependency is
    > non-existent. Thus after the rem target is executed a dependency of inc.h
    > is perforce more recent than inc.h and so inc.h must be recreated.
    >
    > In sum the notion that all things with a current time stamp are equally new
    > misses a subtlty that is important both in theory and in practice.

    Our view differs on historical practice of the original make utility behavior
    This is based from knowledge of the source code and change history we have from
    Bell Labs' PWB to what we have today. That it has generally worked is not in
    doubt but it could not be guarenteed to be so from our knowledge of the
    make utility.

    We agree that what is being described by the testsuite developers, which
    we know as a full transitive closure on the dependency tree is a *better*
    make system. But we point out that it is documented in CS literature, and
    has been stated as a deliberate choice by Feldman (the originator of make)
    not to take this full transitive closure approach. Other make tools,
    "mk" for example, take the full transitive closure approach, and are it
    is felt as better for it. But importantly they are not "make".

    Even though we don't claim conformance to the XCU make definition and
    so are not running any make test assertions we believe the language here
    does not specify a full transitive closure on the dependency tree either
    and extra clauses would be needed to do this.

    The XCU make definition in this area says much the same as our own
    make man page, although in a more fuller wording.

    This whole issue though over the functionallity of make is irrelevant to
    this issue as we have decided not to claim the XCU DEVELOPMENT option even
    if it did specify a full transitive closure on the dependency tree. The
    problem is that make is being used to build the testsuite and although
    this is not unreasonable assumptions like those specified cannot as
    expected on an implementation undertest cannot be guarrenteed.

    This problem is not a failure of a test assertion but a intermittent
    failure in the build process of these tests. We request then a waiver
    against the build system.

    Test Output
    > > 70||"SPEC1170TESTSUITE AREA sys/stat.h 17"
    > > 110|0 /tset/CAPIheaders/hstat/hstat1 18:40:44|Build Start, scenario ref 870-1
    > > 130|0 0 18:40:45|Build End
    > > 110|1 /tset/CAPIheaders/hstat/hstat2 18:40:45|Build Start, scenario ref 871-1
    > > 130|1 0 18:40:46|Build End
    > > 110|2 /tset/CAPIheaders/hstat/hstat3 18:40:46|Build Start, scenario ref 872-1
    > > 130|2 0 18:40:48|Build End
    > > 110|3 /tset/CAPIheaders/hstat/hstat4 18:40:48|Build Start, scenario ref 873-1
    > > 130|3 0 18:40:49|Build End
    > > 110|4 /tset/CAPIheaders/hstat/hstat5 18:40:49|Build Start, scenario ref 874-1
    > > 130|4 0 18:40:50|Build End
    > > 110|5 /tset/CAPIheaders/hstat/hstat6 18:40:50|Build Start, scenario ref 875-1
    > > 130|5 0 18:40:51|Build End
    > > 110|6 /tset/CAPIheaders/hstat/hstat7 18:40:51|Build Start, scenario ref 876-1
    > > 100|6|UX:acomp: ERROR: "hstat7.c", line 61: cannot find include file: <hstat.H>
    > > 100|6|*** Error code 1 (bu21)
    > > 100|6|UX:make: ERROR: fatal error.
    > > 130|6 1 18:40:52|Build End
    > > 110|7 /tset/CAPIheaders/hstat/hstat8 18:40:52|Build Start, scenario ref 877-1
    > > 130|7 0 18:40:53|Build End
    > > 900|18:40:53|TCC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This request should be refused.

    It is not clear to us why the submitter is experiencing this problem but
    the analysis given does not support the conclusion that the test suite
    makefile is the cause.

    As per the SR dialog the submitter quotes above, historical practice is
    that missing prerequisites are considered newer than their targets and
    thus the makefile here is portable and correct. We note for instance
    that the submitter's man page for make says:

    make updates a target only if its dependents are newer than
    the target. All prerequisite files of a target are added
    recursively to the list of targets. Missing files are deemed
    to be outdated.

    We agree with the submitter that full transitive closure is not a universal
    feature of make implementations. However make implementations, this
    vendor's included, have always supported the constructs cited, by virtue
    of make's treating missing files as outdated. This is true for all makes
    and make documentation we have looked at, including the O'Reilly make book.

    Further, we have built these tests literally thousands of times on
    the submitter's implementation and many thousands more on other
    vendors', in some cases on systems considerably faster than what the
    submitter cites. As the majority of the 1000+ VSU header file
    tests use the same make construct at issue here, if the one second
    granularity of file system time stamps were causing this problem we
    should be seeing it many times in each run. Yet we have never seen
    it at all.

    In sum, both analytical and empirical evidence belies the submitter's
    analysis of the problem which thus does not offer a basis for a TSD.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This does not appear to be a branding issue and should be
    dealt with via the support route.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority