Juan Jose Garcia-Ripoll wrote:
>
> On Monday, April 11, 2011 8:48:58 PM UTC+2, Waldek Hebisch wrote:
> >
> > Juan Jose Garcia-Ripoll wrote:
> >
> > > - I use OS X. This is another reason why I was not able to use the
> > > graphical interface: one has to explictly supply --x-includes and
> > > --x-libraries. Would it be possible to automatically detect this?
> >
> > I do not know: FriCAS uses autoconf. So it should work or fail in
> > similar way as other autoconf-using programs.
> >
> I guess the problem is that the standard include path does not include
> /usr/X11/include. It is odd, but it is so in OS X. Maybe a hint in the
> README would suffice.
>
> > Could you send me output of 'configure' (in particular 'config.log')?
> >
> As I said
> ...
> configure:7585: gcc -o conftest -g -O2 conftest.c -lX11 >&5
> ld: library not found for -lX11
> collect2: ld returned 1 exit status
That is error from the linker, so presumably something like
'-L/usr/X11/lib' is missing. If OS X has established convention
where to find X libraries we could try to add appropriate '-L...'
option to linker flags. But on most systems this on not that
easy: locations change in newer versions, there is difference
between 32 and 64 bits, etc. Googling suggests that at least
some OS X versions simply keep X libraries in /usr/lib (in such
case the test above should pass).
> Apparently you are building on case-insentive filesystem (otherwise
> > there should be no conflict between "FLOAT.h" and "float.h").
> >
> Indeed, and this was the only source of problems. The rest seems just fine.
>
>
> > If you have build FriCAS (or build advanced far enough) then
> >
> > )set break break
> >
> > at FriCAS command line make FriCAS error handler execute "BREAK"
> >
> The problem is that FriCAS does not finish building and the SBCL image does
> not even boot properly. BTW, answering Xiaojun's question, I am using a more
> recent version of SBCL, 1.0.45, shipped with Fink for 64bits.
>
> I would like to know what happens with the ECL build and why it does not
> work. Is it possible to set up a similar handler somewhere in the boot
> scripts forcing FriCAS to enter the lisp debugger or something like that?
>
I am affraid we are miscomunicating. FriCAS build system works
like build system of C program with main difference beeging that
instead of calling C compiler FriCAS uses commands like:
echo '(progn (boottran::boottocl "$<" "$@") (${BYE}))' | ${DEPSYS}
In other words appropriate Lisp images reads a command from the pipe.
Since commands are read via pipe it is inconvenient (or maybe even
impossible) to start Lisp debugger from build system. OTOH build
commands only change filesystem and have no persistent effect on
Lisp executing them, so to debug it in enough to execute "by hand"
the failing command. There are several images used during build,
of them 2 give you FriCAS prompt, the other normal Lisp prompt.
If you execute Lisp image like 'depsys' normal Lisp error
handling is in place, so Lisp level errors bring you into debugger
(however for this you need to run command by hand, if commands are
read from pipe then Lisp image just exits).
The main work in first stages of build is done by 'bootsys' and
'depsys'. 'bootsys' and 'depsys' translate Boot code into Lisp.
If any of them discovers error during translation it prints
error message and comes back to the Lisp prompt. As I wrote
Lisp level error in 'bootsys' or 'depsys' get normal Lisp
handling.
I plan to modify 'bootsys' and 'depsys' to exit on errors
with nonzero exit code. Of course, doing that I can add option
to activate Lisp debugger. However, in my experience most
errors during build were Lisp level error so this will change
situation only a little.
Currently debugging build problems is harder than it should be
because Lisp image continues to run after error and eventually
exits with 0 exit code, so 'make' thinks that everything is
OK and runs subseqent commands. Consequently it requires some
effort to find first failing command (the first one usually
is real culprit, the other just a consequence). Exiting with
nonzero code should solve this problem.
BTW: If you send me (via private mail) output of
make > mlogg
I should be able to tell you which command is responsible for
failure and how to debug this failure.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
