Re: [Gcl-devel] gcl-2.6.2 / 303 ansitests failed

[Camm Maguire]

Greetings, and thanks for your interest in GCL!

Christian Cornelssen <address@hidden> writes:

> Dear GCL developers,
> 
> see the subject line.  Is such amount of failures yet to be
> expected?
> 

Yes, this is the expected number of failures.  Our ansi build is still
a work in progress.

> I am new to Lisp, so don't expect debugging skills from me.
> 
> Details:
> 
> I have downloaded gcl-2.6.2 plus the dotimes patch and built it
> with --enable-ansi on an older machine (i586-pc-linux-gnu,
> gcc-2.95.2, binutils-2.11.90.0.29).
> 
> I have GMP-4.1.3 installed, and I did not like the idea of
> overriding mpn/mul_n.o from different GMP versions, so I replaced
> the gmp3/ contents with those of gmp-4.1.3/ and applied gmp.patch
> which moved by some offset, but otherwise fitted perfectly and
> still seems to be justified according to your readme.gpm.
> (I later retried with the original gmp3/ which changed nothing.)
> 

The bug fixed by this patch is only triggered erratically on very
large bignum problems doing lots of garbage collection, so it is hard
to see, but there nonetheless.

> "configure" options other than path settings were:
> --enable-readline --enable-ansi --enable-common-binary=no
> --enable-statsysbfd=no --enable-dynsysbfd --enable-dynsysgmp
> --enable-notify=no
> 
> In case you want to drown in details, I have attached an RPM spec
> file (the interesting parts are in the %prep and %build sections)
> and a build log which also includes test.out contents.
> 

Thank you for this.  Someone else gave us a spec file in the past
too.  Don't know what to do with them.  Is there some standard place
for Redhat rpm distribution using these files?  How does gcl get on
the rpom 'circuit', if anyone wants it there that is?

> I used some scripts for glancing through the logs, so let me
> present the results briefly:
> 
> * No gcc warnings except the following unrelated ones (in gcl-tk/):
> 
> tkMain.c: In function `TkX_Wish':
> tkMain.c:207: warning: passing arg 4 of `Tk_ParseArgv' from incompatible 
> pointer type
> tkMain.c:259: warning: passing arg 2 of `Tcl_Merge' from incompatible pointer 
> type
> 

Thanks, needs fixing.

> * Lots of warnings like:
> 
> Warning: XXX is being redefined.
> 
> (I hope that's ok.)
> 

Yes, is ok.

> * For two files: lsp/gcl_defpackage.lsp pcl/pcl_pkg.lisp
>   warnings of the form
> 
> ; ([...]) is being compiled.
> ;; Warning: The package operation ([...]) was in a bad place.
> 
>   with ([...]) actually looking like a package operation (EXPORT,
>   IN-PACKAGE etc), so I think there is something going wrong.
> 

This is a known and so far harmless disfunction in the package
handling of our compiler.  On the todo list for the next release. 


> * When the ansitests were run, 303 out of 10697 total tests failed.
>   See the attached logfile for details.
>   Perhaps more interestingly, an error was caught:
> 
> Caught error in EXPORT.5: Error in EXPORT [or a callee]: A
> package error occurred on #<"TEST1" package>: "Cannot export
> symbol as it will produce a name conflict.".

The tests deliberately trigger and catch many error conditions in the
course of their work.  I believe this indicates correct functionality
in this case.

> 
> * As mentioned above, I rebuilt with 2.6.2's original gmp3/ which
>   changed essentially nothing: neither the build warnings, nor
>   the test outputs.  I did some filtering of the logs, making all
>   hex and oct address samples in the test outputs equivalent, in
>   order to get an informative diff result.  Which said: no change.
> 

Using locally compiled and external/dynamic libgmp should produce the
same result, as the local patch overrides the routine in the external
lib even in the dynamic link case.  Check out the -u option to the gcc
linker.  

> The attached logfile actually is from a third build with "my" GMP
> re-enforced.  No change, of course.
> 
> So my questions are:
> 
> * Is this a known state of affairs?

Yes

> * If yes, is there a known fix/workaround?

Sounds like you have a working build.

> * Should I try a CVS checkout?

Only if you want extra ansi compliance, but in general is a much more
moving target.

> * If yes, from where?
> 

export CVS_RSH=ssh
export CVSROOT=:ext:address@hidden:/cvsroot/gcl

cvs -z9 -q co -d gclcvs-2.7.0 gcl

or

cvs -z9 -q co -d gcl-2.6.2 -r Version_2_6_2 gcl

Take care,

> Regards,
> 
> Christian Cornelssen
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah