Updated installation instructions
Waldek Hebisch
them as new INSTALL and to put them on SourceForge. Any comments
welcome.
-----------------------------------------------------------------
Quick installation:
FriCAS now tries to support standard GNU build/installation
conventions. So if you have sources and all prerequisities
just:
configure && make && make install
should work. The above will install FriCAS files in
/usr/local/lib/fricas directory and put fricas command in
/usr/local/bin directory, you can give arguments to configure
to change those locations.
NOTE!! If you use svn (minimal version) the above will install broken
HyperDoc pages -- all graphic examples will be missing (and trying to access
them will crash hypertex).
The get working graphic examples login into X and replace 'make' above by
the following:
make
cd src/paste
make gphts
cd ../..
make
Important: building graphic examples accesses the X server, so it will
not work on text console. During build drawings will temporarly
appear on the screen. Redirecting X via ssh should work fine,
but may be slow.
It is also possible to use xvfb-run program, replacing 'make gphts'
above by:
xvfb-run --server-args="-screen 0 1024x768x24" --auto-servernum -n 0 make gphts
--------------------------------------------------------
Prerequisities:
- Lisp, one of:
* GCL, 2.6.7 or prerelease 2.6.8
* sbcl, 1.0.7 or later
* clisp, 2.41 or later
* Closure CL (former openmcl), starting from openmcl 1.1 prerelase
070512
* ECL, 0.9j or later
GCL currently is best tested, but on some platforms there are known
build problems. All Lisp impementations should give essentially
the same functionality. Gcl sources are included in full+gcl distribution
tarball.
- noweb literate programing tool (http://www.eecs.harvard.edu/~nr/noweb/).
Noweb sources are included in full distribution tarball.
- X libraries and headers (includig Xpm library).
On debian (or Ubuntu) you probably need: libx11-dev, libxt-dev, libice-dev,
libsm-dev, libxau-dev, libxdmcp-dev, libxpm-dev.
- Extra libraries needed by gcl. If you use Debian gcl you probably
need libreadline5-dev, libncurses5-dev, libgmp3-dev, libxmu-dev and
libxaw7-dev.
Known problems:
- On Gentoo system installed gcl probably will not work, one need to
build own one.
- Older version of gcl are incompatible with Fedora "exec-shield" and
strong addess space randomization (setting randomize_va_space to 2).
Newest CVS version of 2.6.8 branch of gcl fixes this problem.
- gcl needs bfd library. Many Linux systems include version of bfd
library which is incompatible with gcl. Using the following configure
line should fix this problem:
./configure --disable-xgcl --disable-dynsysbfd --disable-statsysbfd --enable-locbfd
- Boehm garbage collector included in ECL (version 6.8) is incompatible
with Fedora strong address space randomization (setting randomize_va_space
to 2). Using newer version of Boehm garbage collector (7.0 or 7.1)
should solve this problem.
- ECL 0.9j has serious performance problems. ECL version 0.9l is much
faster.
- ECL up to version 0.9l may segfault at exit. This is usually harmless,
but may cause build to hang (for example when generating ug13.pht). Using
CVS version should fix this problem.
- In general, any error when generating documentation will cause build to hang.
- Closure CL earlier than release 1.2 (former Openmcl) has a bug in Lisp
printer. This bug causes incorrect printing of FriCAS types. Also,
Closure CL earlier than release 1.2 has bug in compex
cosine function. Those bugs are fixed in release 1.2. If you want to
use earlier version you can work around the bugs applying
the 'contib/omcl.diff' patch and recompiling the compiler (see the patch
Closure CL documentation for instructions).
--------------------------------------------------------
Getting Lisp.
To build FriCAS you need to install Lisp first. You need
_one_ of the following:
- sbcl
http://sbcl.sourceforge.net/platform-table.html
- Closure CL
http://ccl.clozure.com/manual/chapter2.2.html#id357702
ftp://ftp.clozure.com/pub/release/1.2
- ECL
- gcl, older versions have various problems, CVS version is
better. To get latest stable version from CVS use the
following command
cvs -d:pserver:anon...@cvs.savannah.gnu.org:/cvsroot/gcl co -r Version_2_6_8pre -d gcl-2.6.8pre gcl
In case of build problems try the following configure line
./configure --disable-xgcl --disable-dynsysbfd --disable-statsysbfd --enable-locbfd
- clisp
--------------------------------------------------------
Step by step instructions for first time users:
Latest (developement) version of FriCAS is available only
via svn, so you need svn client (see http://subversion.tigris.org/).
You also need Lisp -- see links in section "Getting Lisp" and
follow instructions.
0) Change to a directory with enough (1.2 GB) free space
1) Fetch sources:
svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas
2) Fetch nonstandard prerequisities:
cd fricas
mkdir zips
cd zips
wget https://axiom.svn.sourceforge.net/svnroot/axiom/trunk/axiom/zips/noweb-2.10a.tgz
2a) Go back to first directory
cd ../..
3) Create build directory and change to it:
mkdir ax-build
cd ax-build
4) Configure. Assuming that you want axiom files to be installed in
/tmp/usr
../fricas/configure --with-lisp=/path/to/your/lisp --prefix=/tmp/usr
where /path/to/your/lisp is name of your Lisp (for example sbcl)
5) Build and install:
make
make install
If you want graphic examples read the note before.
--------------------------------------------------------
Extra information about installation:
The preferred way to build FriCAS is to use already installed
Lisp and noweb. Also, it is preferable to use a separate build
directory. Assuming that source tree is in fricas subdirectry,
you build in ax-build subdirectry and your Lisp is called sbcl
the following should just work:
cd ax-build
../fricas/configure --with-lisp=sbcl && make && make install
Alternatively, if you use gcl you can just put gcl sources as a
subdirectory (called gcl) of fricas directory -- in this case the build
process should automatically build gcl and later use the freshly
build gcl.
Currently --with-lisp option accepts all supported lisp variants, namely
sbcl, clisp, ecl, gcl and Closure CL (openmcl). Build machinery
must know which Lisp variant is in use. gcl, sbcl, clisp and ecl
can be autodetected, for Closure CL (openmcl) one has to give an
extra argument --with-lisp-flavor=openmcl (you can also specify
flavor for other Lisps, but this argument is required only for
Closure CL (openmcl)).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
On 10/25/2008 05:33 PM, Waldek Hebisch wrote:
> Below are updates to installation instructions. I plan to commit
> them as new INSTALL and to put them on SourceForge. Any comments
> welcome.
Before I comment on your new INSTALL...
I recently realised that the the build system does *not* by default
build the aldor-interface if all the aldor tests pass. It is currently
still necessary to add "--enable-aldor" on the configure command line.
I would actually like to add a patch so that the documentation in
configure.ac corresponds to the code, i.e. default should be, if all
tests are OK, the aldor-interface should be built (no "--enable-aldor"
necessary).
What do you think?
Ralf
Waldek Hebisch
OK. Note that I would like to create release branch soon (in a day or
two) and limit changes on branch to critical fixes, so if you want
this change in the next release please do this as fast as possible.
BTW. I think that we should have a short file called README.Aldor
(or maybe INSTALL.Aldor) containing link to Aldor site and explanation
what is needed to build the Aldor interface (in particular, which
files to fetch if svn automation fails).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> two) and limit changes on branch to critical fixes, so if you want
> this change in the next release please do this as fast as possible.
OK, if you don't receive something today, that aldor-related stuff can
wait until the next next release.
> BTW. I think that we should have a short file called README.Aldor
> (or maybe INSTALL.Aldor) containing link to Aldor site and explanation
> what is needed to build the Aldor interface (in particular, which
> files to fetch if svn automation fails).
Of course, but as you see from src/aldor/Makefile.in, there is partially
already some hints included.
---BEGIN part of Makefile.in
###################################################################
# 3. Dependencies of a few aldor files given by $(aldor_srcs).
###################################################################
# The files in aldor_srcs are not yet under a license
# that is appropriate for inclusion in an Axiom repository.
# These files are available from aldor.org
# ALDORSVN=https://aquarium.aldor.csd.uwo.ca/svn/
# or from a parallel development site
ALDORSVN=https://svn.origo.ethz.ch/algebraist
ALDORBASICS=$(ALDORSVN)/trunk/aldor/lib/libax0
ALDORLANG=$(ALDORSVN)/trunk/aldor/lib/axllib/src
SVN:=@SVN@
ifdef SVN
SVNCAT=$(SVN) cat
else
SVNCAT:=echo Get the file manually from
endif
axiom.as axextend.as axlit.as stub.as:
$(SVNCAT) $(ALDORBASICS)/$@ > $@
---END part of Makefile.in
So the process will fails anyway if the aldor files are not available.
If SVN is there and internet, everything is fine. If no SVN is there,
one should find out from the log, what to do. The only problem is
"have_SVN and dont_have_Internet" at make time.
I'll try to come up with a INSTALL.aldor text.
Ralf
Ralf Hemmecke
I was thinking about allowing to get the necessary external aldor files
not only via svn but also via wget. That works already locally here. But
I faintly remember that there was another program like wget, I just
don't recall its name. Some idea?
Ralf
Ralf Hemmecke
> BTW. I think that we should have a short file called README.Aldor
> (or maybe INSTALL.Aldor) containing link to Aldor site and explanation
> what is needed to build the Aldor interface (in particular, which
> files to fetch if svn automation fails).
Here is an attempt for INSTALL.aldor.
Ralf
mabshoff
> I was thinking about allowing to get the necessary external aldor files
> not only via svn but also via wget. That works already locally here. But
> I faintly remember that there was another program like wget, I just
> don't recall its name. Some idea?
available per default while wget is not.
> Ralf
Cheers,
Michael
Waldek Hebisch
Waldek Hebisch
> Here is an attempt for INSTALL.aldor.
>
OK.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> Here is an attempt for INSTALL.aldor.
>
> 4. Make a VPATH (or out-of-source) build of FriCAS.
> cd /path/to/builddir
> /path/to/fricas-src/configure --prefix=/path/to/installdir --enable-aldor
> make
>
> 5. If "make" finished successfully then type "make install" and the
> FriCAS and the interface is installed.
> In case the build failed because of missing one of the above files,
> get those files with a web browser and put them under
> /path/to/builddir/src/aldor. Then say
> cd /path/to/builddir && make && make install
>
Are you sure this is correct? Last time I tried, when build failed
due to missing files I had to clean aldor subdirectory and restart
from scratch. I think that there were several wrongly generated files.
Given that I would rather write the above as:
4a. Configure an out-of-source build of FriCAS.
cd /path/to/builddir
/path/to/fricas-src/configure --prefix=/path/to/installdir --enable-aldor
[4b. ] If you had (or expect) problems due to missing files get the files
listed above and put them under /path/to/builddir/src/aldor.
4c. Make:
make
5. If "make" finished successfully then type "make install" and the
FriCAS and the interface is installed.
In case the build failed because of missing one of the above files,
clean to aldor subdirectory:
cd /path/to/builddir/src/aldor && make clean
and go back to 4b.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
It would be helpful if someone really experienced such a problem.
You might be right in at least removing a partial libaxiom.al. I'll try
to check that.
Ralf
leh...@bayou.uni-linz.ac.at
> I don't think you are right, but I'll re-check tonight.
> It would be helpful if someone really experienced such a problem.
when there was no connection to the svn server,
an empty file axiom.as etc was created and the build
continued until the files were actually needed.
At least these empty files had to be removed before
restarting the build. Perhaps this has changed in the meantime.
Franz
Ralf Hemmecke
more fool proof than changing the install instructions.
Ralf
Ralf Hemmecke
Linux at least (without waiting for a timeout) whether there is an
internet connection or not.
Something like
HAVEINET=$(shell if svn list ${REMOTEREPO} > /dev/null; then echo 1; fi)
works for me quite nicely, but I cannot rely on SVN.
Ralf
On 10/29/2008 08:37 AM, leh...@bayou.uni-linz.ac.at wrote:
Bill Page
Shouldn't you just check return codes from svn, wget or curl?
Regards,
Bill Page.
Ralf Hemmecke
Ah, of course. ... But then ... MAKE is actually doing that for me. Only
that
axiom.as axextend.as axlit.as stub.as:
$(SVNCAT) $(ALDORBASICS)/$@ > $@
aborts with an error and leaves an empty file $@, i.e. axiom.as. So I
guess, I have to wrap this into an if-statement.
axiom.as axextend.as axlit.as stub.as:
if $(SVNCAT) $(ALDORBASICS)/$@ > $@.tmp; then \
mv $@.tmp $@; \
else \
rm $@.tmp; false;
fi;
or forget about the "else" branch and add "rm *.tmp" to the "clean" target.
Ralf
Ralf Hemmecke
Instead of changing INSTALL.aldor, I'd like to get your permission to
add the following patch.
I've tested it with and without Internet. And I don't see where else it
can go wrong.
I somehow don't like the 3 ifs so much, but I don't know how to make it
shorter.
Ralf
woodpecker:~/SVK/fricas/src/aldor>svk diff Makefile.in
=== Makefile.in
==================================================================
--- Makefile.in (revision 2548)
+++ Makefile.in (local)
@@ -45,7 +45,7 @@
-rm easylist.lsp
-rm libaxiom.lst aldordepfiles domaindepfiles
-rm -rf tmp init_ap gendeps ap ao al
- -rm cliques*
+ -rm cliques* *.tmp
###################################################################
@@ -157,28 +157,40 @@
CURL:=@CURL@
WGET:=@WGET@
ifdef SVN
- SVNCAT=$(SVN) cat
+ CATURL=$(SVN) cat
else
ifdef CURL
- SVNCAT:=$(CURL)
+ CATURL:=$(CURL)
else
ifdef WGET
- SVNCAT:=$(WGET) -O -
+ CATURL:=$(WGET) -O -
else
- SVNCAT:=echo Get the file manually from
+ CATURL:=echo Get the file manually from
endif
endif
endif
axiom.as axextend.as axlit.as stub.as:
- $(SVNCAT) $(ALDORBASICS)/$@ > $@
+ if $(CATURL) $(ALDORBASICS)/$@ > $@.tmp; then \
+ mv $@.tmp $@; \
+ else \
+ rm $@.tmp; false; \
+ fi
minimach.as:
- $(SVNCAT) $(ALDORBASICS)/$@ | \
- sed -e 's/^#.*//;s/Language;/AxiomLib;inline from AxiomLib;/' > $@
+ if $(CATURL) $(ALDORBASICS)/$@ > $@.tmp; then \
+ sed -e 's/^#.*//;s/Language;/AxiomLib;inline from AxiomLib;/' $@.tmp
> $@ && \
+ rm $@.tmp; \
+ else \
+ rm $@.tmp; false; \
+ fi
lang.as:
- $(SVNCAT) $(ALDORLANG)/$@ > $@
+ if $(CATURL) $(ALDORLANG)/$@ > $@.tmp; then \
+ mv $@.tmp $@; \
+ else \
+ rm $@.tmp; false; \
+ fi
subsetc.as: stub.as
grep AxiomLib $< > $@
Waldek Hebisch
>
> Waldek,
>
> Instead of changing INSTALL.aldor, I'd like to get your permission to
> add the following patch.
>
> I've tested it with and without Internet. And I don't see where else it
> can go wrong.
>
> I somehow don't like the 3 ifs so much, but I don't know how to make it
> shorter.
>
> Ralf
>
1) I think than in rules instead of ifs it is better to use
construct like this:
$(CATURL) $(ALDORLANG)/$@ > $@.tmp && mv $@.tmp $@
(and let the clean rule remove trash files).
2) If you define
CATURL:=echo Get the file manually from
then it looks that the *.as rules will silently produce
files containing error message, so we will still have
problem. We should rather add extra rule which checks if
the needed files are present and stops build with error
message otherwise.
3) I also think that even if problem with restarting make is
fixed current INSTALL.aldor is misleading by omission:
it says to fetch extra files after make fails, while
if failure is expected than the most convenient moment
is after configure. So, while running make clean may
be unnecessary, other changes to INSTALL.aldor still apply.
Let me also say that I consider changing INSTALL.aldor a
low cost option: I checked that the procedure works on
my machine and it is reasonable to expect that it will
cause no extra breakage on other machines. OTOH changes
to Makefiles require testing. Still, if you want to
change Aldor interface Makefiles please go on.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> like this:
>
> $(CATURL) $(ALDORLANG)/$@ > $@.tmp && mv $@.tmp $@
>
> (and let the clean rule remove trash files).
I like that. Thanks.
> 2) If you define
>
> CATURL:=echo Get the file manually from
>
> then it looks that the *.as rules will silently produce files
> containing error message, so we will still have problem. We should
> rather add extra rule which checks if the needed files are present
> and stops build with error message otherwise.
OK, sounds reasonable.
> 3) I also think that even if problem with restarting make is fixed
> current INSTALL.aldor is misleading by omission: it says to fetch
> extra files after make fails, while if failure is expected than the
> most convenient moment is after configure.
I actually would like configure to tell me about the problem of missing
files. But then I don't like to duplicate the names of these
files to two places. Well, it is a fixed set and will not suddenly
change in the future... (except these files become free) so moving
everything (including an attempt to download those files) to configure
time seems to be a good idea.
But... assume ./configure does not fail and has all the prerequisites
(including the file download) for the Aldor interface. Then of course
"make clean" should not remove those files, only "make distclean", right?
> So, while running make clean may be unnecessary, other changes to
> INSTALL.aldor still apply.
> Let me also say that I consider changing INSTALL.aldor a low cost
> option: I checked that the procedure works on my machine and it is
> reasonable to expect that it will cause no extra breakage on other
> machines. OTOH changes to Makefiles require testing.
You are right. The modified INSTALL.aldor is attached. I modified it
according to your suggestion.
> Still, if you want to change Aldor interface Makefiles please go on.
I now rather tend to move this download stuff to configure time. Any
pros and cons?
Anyway, don't delay the release just because of the Aldor interface.
Ralf