gmp config + propagating errors at top level compile

Greetings, and thank you again for your thorough development and
maintenance of these programs!

William Schelter <wfs@nicolas.ma.utexas.edu> writes:

>  in the configure of gcl, I included 
>  (cd gmp ; ./configure --target=pentium) ;;
> 
> I intended to include a line in the gcl/configure.in to make the
> configuration on any pentium, 686, pentiumpro, athlon etc use pentium

This is a fine solution as well.  I just uploaded last week a package
configured as a '486'.  Question: how much does maxima use the gmp
code?  How significant is the tuning of this library on the typical
overall performance of maxima?  Because it also appears as though the
shared lib approach will work.  This wastes disk space (~ 300k in the
included gmp sublib!) but provides a more optimal binary across
subarchitectures, provides a seamless cpu upgrade path, as well as
support for nfs mounting /usr across a LAN, etc.  I really don't know
how to evaluate the tradeoff.  

> which I think should work for almost all machines now adays.  This
> would hurt performance a bit, but at least let the same binary work on
> all.  However, the '[' ']' got stripped in the making of configure
> from configure.in and the test regexp i5-986* |pentium* | ...  which
> would not match lots, and so the default configure is used for those
> machines.  Ie a more machine specific one.  So you could just fix the
> above in the configure.  I am still unsure what the best target to use
> would be..  On the machine I was running on I found that the
> distributed shared gmp.so was actually compiled incorrectly for my
> architecture, and so gave a segfault on certain gcl operations.   That

That's alarming.  Hope it wasn't a Debian box :-)  If by chance it
was, please consider reporting it as a bug. 

> is part of the reason I include the part of gmp we need, to make sure
> it is compiled correctly.   Also I needed to include it to make some changes
> to functions to help the gc.  
> 

Yes this latter is especially important, AFAICT.  You state that you
replace a malloc with a tmp-alloc in one of the mpn files.  Does this
"help" gcl, or is it required to make it function correctly?  Have you
by any chance had the opportunity to request the gmp authors to
consider including this change?  Of course it would be cleaner if one
could avoid duplicating the gmp code/source, but a safe correct
functionality is of course the highest priority.

Can you foresee any problems compiling against an installed gmp
library version 2.0.2?


>  case "${canonical}" in
>    i[5-9]86* | pentium* | k6* | athlon*)
>       (cd gmp ; ./configure --target=pentium) ;;
>    *)
>       (cd gmp ; ./configure) ;;
>  esac
> 
> 
> ==================
>   this is a message from gcc.   Yes I probably dont have gcl return
>   with a nonzero 
> 
> plot.c: In function `L84':
> plot.c:9924: virtual memory exhausted
> cpp: output pipe has been closed
> 
> Yes it would appear that gcl was not propagating correctly the failure
> to compile due to gcc running out of space.   I have fixed this in
> unixport/init_gcl.lsp:   On a more practical note, if you run out of space
> like that you can remove the -pipe from the gcc flag, and it should
> use temp files, which will take less swap space. 
> 

Thanks for this!  Actually, in general I have plenty of space -- I was
just abusing the box at the moment a wee too much :-)!

> (defun system::gcl-top-level (&aux tem)
>   (si::set-up-top-level)
> 
>   (if (si::get-command-arg "-compile")
>         (let ((*break-enable* nil) result)
>              (setq result
> 		   (system:error-set
> 		    '(progn
> 		       (compile-file
> 			(si::get-command-arg "-compile")
> 			:output-file 
> 			(or (si::get-command-arg "-o")
> 			    (si::get-command-arg "-compile"))
> 			:o-file
> 			(cond ((equalp
> 				(si::get-command-arg "-o-file")
> 				"nil") nil)
> 			      ((si::get-command-arg "-o-file" t))
> 			      (t t))
> 			:c-file (si::get-command-arg "-c-file" t)
> 			:h-file (si::get-command-arg "-h-file" t)
> 			:data-file (si::get-command-arg "-data-file" t)
> 			:system-p (si::get-command-arg "-system-p" t)))))
>              (bye (if (or compiler::*error-p* (equal result '(nil))) 1 0))))
>   (cond ((si::get-command-arg "-batch")
>          (setq si::*top-level-hook* 'bye))
>         ((si::get-command-arg "-f"))
>         (t  ;; if ANY header or license information is printed by the
>             ;; program, then the following License and Enhancement notice
>             ;; must be printed (see License).
> 	 (format t "GCL (GNU Common Lisp)  ~A~%~a~%~a~%" "DATE"
> 		 "Licensed under GNU Library General Public License"
> 		 "Contains Enhancements by W. Schelter")))
>      (setq si::*ihs-top* 1)
>   (in-package 'system::user) (incf system::*ihs-top* 2)
>   (funcall system::*old-top-level*))
> 
> 
> 
> 

One final unrelated question -- do you know of any other applications
atop gcl?  Right now, the maxima build includes a gcl sub-build as
part of the process.  I'm considering reworking this to make a gcl-dev
package for Debian, and was wondering if there was any other code that
could benefit.




Take care,

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