[Top][All Lists]

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

RE: [Axiom-developer] axiom.silver

From: Gabriel Dos Reis
Subject: RE: [Axiom-developer] axiom.silver
Date: Mon, 11 Sep 2006 18:26:40 -0500 (CDT)

On Mon, 11 Sep 2006, Page, Bill wrote:

| Gaby,
| On Monday, September 11, 2006 12:26 PM you wrote:
| >
| > On Mon, 11 Sep 2006, root wrote:
| >
| > | > The error from the configure is this:
| > | > *******************************************
| > | > Darwin
| > | > Your system name is Darwin
| > | > We do not know how to build for this kind of system
| > | > Send a note to address@hidden about it
| > | > *******************************************
| > |
| > |
| > | Actually, this is correct. I do not yet know how to build
| > | Axiom on a MAC. There has been a recent suggestion that we
| > | use Xcode and I'm pursuing that path.
| >
| > Tim --
| >
| >   Jacob is a student at TAMU taking my class on symbolic
| > computations. He is interested in provisos -- I suspect at
| > some point he may get into touch with you. He is trying to
| > build Axiom for his class work.
| >
| > From what I understand, Bill has been able to build the
| > build-improvements branch with some patches from Camm (which
| > I believe I already put in build-improvements).
| I have built the build-improvements branch on the axiom-developer
| server (in fact that is what is running on MathAction right now).
| But I think the build process still has some problems. For example,
| I am not able to build (even if I specific '--without-noweb') if
| noweb is not previously installed and in the PATH.

I think I fixed that, as per my conversation with Waldek

| Also, the
| option to build from a previously installed gcl does not work
| so the option '--without-gcl' is still necessary. Since building
| from pre-installed gcl is possible on Debian using the Debian
| source distribution for Axiom, there must still be something
| missing from the 'gcl-system' option in the build-improvements
| branch.

As per discussion with Waldek, I'm able to reproduce the failure on
the SF compile farm host debian system.  For long time I've blamed GCL
for not finding its own internal files.  I had had several "fixes" -- none
of which I liked, because I felt they were ugly.  I finally nailed
down the real source (I think): It is caused by this line in
src/interp/Makefile.pamphlet for building interpsys

 @ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >>  

That setting of *system-directory* fools GCL's logic for invoking GCC
to compile the intermediate C code.  I don't see any reason why Axiom
would want to set that variable if it is not going to copy whole
/usr/local/lib/gcl-x.y.z (or wherever that directory is) -- and I
don't see any reason why it should do so.  As I'm writing this mail, I
have a build going on.  Hopefully that would settle the issue.

Notice that fixing that bug also opens the door for reducing the
number of Axiom-specific patches we have to apply to our copy of GCL

| There is also an additional patch which I am still discussing
| with Camm to solve the "Can't rename' problem. The patch that
| I am using now might not be the ultimate solution of gcl-2.6.8.

Thanks for the update.  Let me know once you guys have decided on what
is the good way to fix that problem.

| Until a few days ago, I was also working on the SourceForge
| compile farm - specifically on the OS X build. But SourceForge
| currently has a network configuration problem which prevents me
| from accessing their servers:
| up_id=1

Yes.  I intended (last week-end) to post the list of hosts that I
can't connect to (the vast majority of them), and the list of hosts
lacking latex. The work on out-of-source build finally got me to a
point where I just needed to svn checkout from a "good host" and
seamlessly build on other machines (as user directories are
automounted everywhere).

| > I have a fix for the debian failure.  Once that is in, I would
| > like to make a tarball of build-improvements available from
| > or from SF (whichever is OK with you).
| > This is to remove the "random" checkout errors.
| >
| I also continue to see some svn checkout errors. In some cases
| on some platforms this seems to be a recoverable error by just
| repeating the 'svn co' command until the checkout completes. On
| others, the local svn archive gets unrecoverably locked. :(
| I wonder if this might be another network configuration problem
| at SourceForge?

Very likely.

| Maybe we should setup a mirror of the SourceForge SVN repository
| on the server? Then at least we would have an
| alternate site in case there is a network problem.

I'm not a big fan of project sources scattered all over the place with
sync snafus, but I'm definitely for a good solution that removes the
network problem out of the way.  Hopefully, now that we have
out-of-source  build, people would no longer need to "rm -rf" the
wholse source.

-- Gaby

reply via email to

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