[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] tan compilation problem

From: Vadim V. Zhytnikov
Subject: [Gcl-devel] tan compilation problem
Date: Wed, 07 Aug 2002 00:46:26 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526


I've been trying to figure out why Maxima 5.9.0 (CVS) fails to
build on gcl 2.5.0 if the latter is build with --enable-bfd
and it seems to me that I've managed to localize (but not resolve)
the trouble quite well.

Let's take very simple file test.lsp which
contains two almost trivial function definitions
------- test.lsp ------------------

(defun mysin (x)
    (declare (type double-float x))
    (sin x))

(defun mytan (x)
    (declare (type double-float x))
    (tan x))


I build two saved_gcl images. First with --disable-bfd
and second with --enable-bfd.  When I make
  (compile-file "tests")
Not surprisingly resulting test.o is absolutely the same
for both saved_gcl versions.  nm test.o lists U tan and
U sin among other symbols.

The difference reveals when I try to load test.o
  (load "test")

First saved_gcl (no bfd) successfully loads the file but
issues the warning:
  symbol "tan" is not in base ...
Notice that it complains about tan but not about sin.
In spite of successful load mytan doesn't work since
any attempt to evaluate (mytan ...) results in internal
lisp error ("memory may be damaged..." and so on).
On the contrary mysin works fine.

Second saved_gcl (with bfd) rejects the file with the
error message:
  tan is undefined
  Error: Cannot get relocated section contents
So bfd-enabled saved_gcl is actually smarter
and reveals the problem immediately.

I think that it is not necessary to say that
if I remove mytan then test.lsp with mysin
works fine for both saved_gcl images.

And finally problem disappear if I remove
  (declare (type double-float x))
in both function definitions.

It seems that there is some problem with
tan in GCL. I wonder why it is so different
from sin?

Best wishes,


     Vadim V. Zhytnikov


reply via email to

[Prev in Thread] Current Thread [Next in Thread]