Missing dependancy in spkg/standard/deps for zn_poly.

[sagetrac-drkirkby]

The zn_poly package lists in SPKG.txt the only dependencies are GMP, but this is not true, as zn_poly's configure script has in it:

/configure --gmp-prefix="$SAGE_LOCAL" --ntl-prefix="$SAGE_LOCAL" \
            --prefix="$SAGE_LOCAL" --cflags="$CFLAGS" --ldflags="$LDFLAGS"

So zn_poly depends on ntl

Looking at $SAGE_ROOT/spkg/standard/deps, I see:

$(INST)/$(ZNPOLY): $(BASE) $(INST)/$(MPIR)
        $(INSTALL) "$(SAGE_SPKG) $(ZNPOLY) 2>&1" "tee -a $(SAGE_LOGS)/$(ZNPOLY).log"

i.e. no such dependency is directly listed.

Then looking at MPIR I see the dependencies are only BASE and ICONV. But ICONV only depends on BASE, so there is nothing to force ntl to build before zn_poly, despite zn_poly depends on ntl

I am aware of two other changes that are desirable in the 'deps' file too, as they add clarity.

• R depends on Fortran, but has no such dependancy in spkg/standard/deps #9464
• SAGETEX does not show a dependancy of BASE in spkg/standard/deps #9637

These might as well be fixed at the same time.

Dave

CC: @dandrake @qed777 @nexttime @jhpalmieri

Component: build

Author: David Kirkby

Issue created by migration from https://trac.sagemath.org/ticket/9681

[sagetrac-drkirkby]

Attachment: deps.gz

Updated deps file, which solves this major problem and corrects two minor ones in #9464 and #9637

[sagetrac-drkirkby]

Attachment: deps.diff.gz

Unifier diff file for $SAGE_ROOT/spkg/standard/deps

[sagetrac-drkirkby]

comment:3

I've attached an updated 'deps' file, which fixed this major problem and two minor ones - #9464 and #9637. If this ticket is merged, then #9464 and #9637 can be closed as fixed.

Dave

[sagetrac-drkirkby]

comment:4

It was only by chance I found this, while trying to resolve a 64-bit Solaris issue, which is #9358.

I'm adding the two release managers to the ticket, as I believe this should be a blocker.

Dave

[sagetrac-drkirkby]

Author: David Kirkby

[robertwb]

comment:7

Unless it's actually causing problems for builds, or giving incorrect results, I wouldn't classify this a as a blocker (though I'd say it is a bug for sure).

[sagetrac-drkirkby]

comment:8

Replying to @robertwb:

Unless it's actually causing problems for builds, or giving incorrect results, I wouldn't classify this a as a blocker (though I'd say it is a bug for sure).

Some rather subtle problems have been caused by dependencies which have not been correct - I'm thinking in particular of William's failure on OS X to compile some Fortran code, when in fact it was due to the fortran package being dependent on python for a very simple script. The strange thing about that was everyone else had no problems, including me, using William's script on bsd.math.

I would have thought anything that had the potential to mis-compile would be a blocker personally, but that's a personal opinion of course.

Dave

[sagetrac-drkirkby]

comment:9

Apparently NTL is not needed unless one makes those targets, so this is a non-issue.