Discussion:
gcl build fails with git head
(too old to reply)
Robert Dodier
2017-06-24 06:12:27 UTC
Permalink
Raw Message
Gunter reported a problem with building Maxima HEAD using
GCL 2.6.12 ANSI Fri Apr 22 15:51:11 UTC 2016
(the current version in Debian testing).
I can confirm that this has been a problem for several months down to
today. Those who replied in that thread appeared to be using a different
(earlier?) release of GCL.
For the record I am working with GCL 2.6.12 from the GCL download page
(http://ftp.gnu.org/gnu/gcl/). That is a few years old at this point --
dated Oct 2014. I don't know the origin of Debian's version.

With that version of GCL, I can build and run Maxima successfully. I am
working on Linux (Ubuntu 14.04).

FWIW

Robert Dodier
Gunter Königsmann
2017-06-24 07:25:14 UTC
Permalink
Raw Message
Post by Robert Dodier
I can confirm that this has been a problem for several months down to
today. Those who replied in that thread appeared to be using a different
(earlier?) release of GCL.
For the record I am working with GCL 2.6.12 from the GCL download page
(http://ftp.gnu.org/gnu/gcl/). That is a few years old at this point --
dated Oct 2014. I don't know the origin of Debian's version.
The current pre-alpha of ubuntu ships with gcl 2.6.12-53...
Post by Robert Dodier
./configure --enable-gcl
make -j 1
./configure --enable-gcl --enable-sbcl --enable-ecl
make -j 4
make[1]: Entering directory '/home/gunter/src/maxima-code/src'
gcl -batch -eval '(progn (load "../lisp-utils/defsystem.lisp") (load
"../lisp-utils/make-depends.lisp") (funcall (intern
"CREATE-DEPENDENCY-FILE" :mk) (list "binary-gcl/maxima"
"sys-proclaim.lisp") "gcl-depends.mk") )'
Post by Robert Dodier
Warning: SIMPLE-WARNING: REQUIRE is being redefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by MAKE-PATHNAME.
File error on #p"": Bad directory list
Broken at MAKE-PATHNAME. Type :H for Help.
1 Return to top level.
That would mean that the problem might lay somewhere in our build system.

Kind regards,

Gunter.
Robert Dodier
2017-06-24 19:29:03 UTC
Permalink
Raw Message
Post by Robert Dodier
./configure --enable-gcl
make -j 1
./configure --enable-gcl --enable-sbcl --enable-ecl
make -j 4
The make -j option tells make to run some jobs simultaneously. I don't
see any reason to expect that that is guaranteed to work, especially
since the Maxima build process almost certainly requires some things
to be done before others.

If make -j is the only difference which causes the GCL build to fail
(perhaps you can verify that), then I don't think that's a bug in GCL
nor in the Maxima build system. It is a slight inconvenience but OK.

I don't think I would advise reworking the Maxima build system so that
make -j is successful. It would probably take some pretty strenuous
revision, and the build system is probably pretty fragile.

As I was saying, perhaps you can verify that make -j actually triggers
the error.

best,

Robert Dodier
Gunter Königsmann
2017-06-24 20:17:02 UTC
Permalink
Raw Message
Post by Robert Dodier
The make -j option tells make to run some jobs simultaneously. I don't
see any reason to expect that that is guaranteed to work, especially
since the Maxima build process almost certainly requires some things
to be done before others.
Good idea, that!

=> Re-tried without the "-j 4" immediately.

Seems like without the "-j 4" the error message still appears => either
configuring more than one lisp triggers the problem or I just got lucky
when I tried to compile with gcl alone.

A failed compilation attempt seems to leave the files that trigger the
problem in the source directory (I did an in-source-build):
Doing a
Post by Robert Dodier
./configure --enable-gcl
make
immediately triggered the error message.

Kind regards,

Gunter.
Gunter Königsmann
2017-06-24 20:22:38 UTC
Permalink
Raw Message
Post by Gunter Königsmann
Seems like without the "-j 4" the error message still appears => either
configuring more than one lisp triggers the problem or I just got lucky
when I tried to compile with gcl alone.
Seems I just got lucky the last time: I've just cloned the git master
into a fresh directory.

A

./bootstrap &&./configure --prefix=/usr --enable-gcl&&make

led to:

Making all in src
make[1]: Entering directory '/home/gunter/maxima-code/src'
gcl -batch -eval '(progn (load "../lisp-utils/defsystem.lisp") (load
"../lisp-utils/make-depends.lisp") (funcall (intern
"CREATE-DEPENDENCY-FILE" :mk) (list "binary-gcl/maxima"
"sys-proclaim.lisp") "gcl-depends.mk") )'

Warning: SIMPLE-WARNING: REQUIRE is being redefined.

Error:
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by MAKE-PATHNAME.
Condition in MAKE-PATHNAME [or a callee]: INTERNAL-SIMPLE-FILE-ERROR:
File error on #p"": Bad directory list

Broken at MAKE-PATHNAME. Type :H for Help.
1 Return to top level.
Kind regards,

Gunter.
Robert Dodier
2017-06-25 00:30:09 UTC
Permalink
Raw Message
Post by Gunter Königsmann
./bootstrap &&./configure --prefix=/usr --enable-gcl&&make
File error on #p"": Bad directory list
Hmm. Well, I guess the problem is not make -j, then. Thanks for
investigating.
Post by Gunter Königsmann
Fast links are on: do (si::use-fast-links nil) for debugging
Sorry I can't be more helpful,

Robert Dodier
Thomas D. Dean
2017-06-25 00:46:51 UTC
Permalink
Raw Message
Post by Gunter Königsmann
Post by Gunter Königsmann
Seems like without the "-j 4" the error message still appears => either
configuring more than one lisp triggers the problem or I just got lucky
when I tried to compile with gcl alone.
Seems I just got lucky the last time: I've just cloned the git master
into a fresh directory.
A
./bootstrap &&./configure --prefix=/usr --enable-gcl&&make
Making all in src
make[1]: Entering directory '/home/gunter/maxima-code/src'
gcl -batch -eval '(progn (load "../lisp-utils/defsystem.lisp") (load
"../lisp-utils/make-depends.lisp") (funcall (intern
"CREATE-DEPENDENCY-FILE" :mk) (list "binary-gcl/maxima"
"sys-proclaim.lisp") "gcl-depends.mk") )'
Warning: SIMPLE-WARNING: REQUIRE is being redefined.
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by MAKE-PATHNAME.
File error on #p"": Bad directory list
Broken at MAKE-PATHNAME. Type :H for Help.
1 Return to top level.
I use make -j12 on an i7.

What OS? Which make, gcl?
Post by Gunter Königsmann
cat /etc/os-release | head -2
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
Post by Gunter Königsmann
uname -a
Linux P9X79 4.12.0-041200rc2-generic #201705212331 SMP Mon May 22 \
03:32:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Post by Gunter Königsmann
make --version | head -2
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Post by Gunter Königsmann
/usr/local/bin/gcl --version
GCL (GNU Common Lisp) 2.6.12 ANSI Jul 26 2015 18:48:00
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
<snip>
Post by Gunter Königsmann
Rm -Rf maxima-code
git clone git://git.code.sf.net/p/maxima/code maxima-code
cd maxima-code/
./bootstrap
./configure --enable-gcl
make -j12
sudo make install
/usr/local/bin/maxima
Maxima branch_5_40_base_80_ga55f0b7 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) integrate(sin(1/x),x);
1 %i %i
2 sin(-) x + gamma_incomplete(0, --) + gamma_incomplete(0, - --)
x x x
(%o1) ----------------------------------------------------------------
2

Seems Ok.

Tom Dean
Thomas D. Dean
2017-06-25 00:53:11 UTC
Permalink
Raw Message
On 06/24/2017 05:46 PM, Thomas D. Dean wrote:

Looking at my post, I seem to remember that gcl MUST be built with ANSI.

Maybe this is the problem???

Tom Dean
Gunter Königsmann
2017-06-25 06:12:44 UTC
Permalink
Raw Message
Post by Thomas D. Dean
Looking at my post, I seem to remember that gcl MUST be built with ANSI.
Maybe this is the problem???
Unfortunately not: a non-ansi-gcl will already be detected by configure and leads to an appropriate error message.
...and my system is an I7 with an 64-bit Ubuntu, too.

What I don't understand is, why it sometimes builds fine...
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Gunter Königsmann
2017-06-25 07:14:15 UTC
Permalink
Raw Message
Post by Gunter Königsmann
Post by Thomas D. Dean
Looking at my post, I seem to remember that gcl MUST be built with ANSI.
Maybe this is the problem???
Unfortunately not: a non-ansi-gcl will already be detected by configure and leads to an appropriate error message.
...and my system is an I7 with an 64-bit Ubuntu, too.
What I don't understand is, why it sometimes builds fine...
When the error occurs there is still no src/sys-proclaim.lisp and no
binary-gcl folder, but the first command executed contains these names =>

created the folders

- binary-gcl
- binary-gcl/numerical
- binary-gcl/numerical/slatec

and an empty file named

- src/sys-proclaim.lisp

Afterwards I did a
- touch src/*.lisp
- touch src/*.am

now the gcl build compiles again.

Only creating the .lisp file didn't help, for some reason.
As I am neither an lisp expert nor an expert for our build system I will
stop my debugging works here.

Kind regards,

Gunter.
Thomas D. Dean
2017-06-25 18:10:53 UTC
Permalink
Raw Message
On 06/25/2017 12:14 AM, Gunter Königsmann wrote:

What GCL are you using?

What make?

Tom Dean
Gunter Königsmann
2017-06-25 18:28:53 UTC
Permalink
Raw Message
Post by Thomas D. Dean
What GCL are you using?
What make?
Ubuntu/64 Bit; asv they didn't make a new major release for a long time we all will have the same version number. The last digit for my version seems to be the -53.

I assume the file that I needed to create in order to make compilation work is included in the tarball so I expect a clean git checkout to fail and an official release to work. But I may be wrong in this respect.

Kind regards,


Gunter.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Thomas D. Dean
2017-06-25 19:07:12 UTC
Permalink
Raw Message
Post by Gunter Königsmann
Post by Thomas D. Dean
What GCL are you using?
What make?
Ubuntu/64 Bit; asv they didn't make a new major release for a long time we all will have the same version number. The last digit for my version seems to be the -53.
I assume the file that I needed to create in order to make compilation work is included in the tarball so I expect a clean git checkout to fail and an official release to work. But I may be wrong in this respect.
gcl
GCL (GNU Common Lisp) 2.6.12 ANSI Jul 26 2015 18:48:00
Post by Gunter Königsmann
make --version
GNU Make 4.1

I send the output of my configuration and make, offline.

Tom Dean
Thomas D. Dean
2017-06-25 19:18:23 UTC
Permalink
Raw Message
Post by Gunter Königsmann
Post by Thomas D. Dean
What GCL are you using?
What make?
Ubuntu/64 Bit; asv they didn't make a new major release for a long time we all will have the same version number. The last digit for my version seems to be the -53.
I assume the file that I needed to create in order to make compilation work is included in the tarball so I expect a clean git checkout to fail and an official release to work. But I may be wrong in this respect.
Kind regards,
Gunter.
is the -53 your linux version???
I have linux -4.4.0-81-generic, but, am running 4.12.0-041200rc2-generic
to test a usb bug.

When was the last time you did an Ubuntu dist-upgrade?
'sudo apt-get dist-upgrade'

The gcl from Ubuntu 16.04, seems to be
Post by Gunter Königsmann
gcl
GCL (GNU Common Lisp) 2.6.12 CLtL1 Oct 29 2015 23:21:28
<snip>

This does not seem to be an ANSI gcl.
Post by Gunter Königsmann
make --version
GNU Make 4.1
<snip>

Tom Dean
Gunter Königsmann
2017-06-25 20:20:19 UTC
Permalink
Raw Message
Post by Thomas D. Dean
is the -53 your linux version???
I have linux -4.4.0-81-generic, but, am running 4.12.0-041200rc2-generic
to test a usb bug.
My gcl version ends in -53: 2.6.12-53.

The kernel shouldn't cause problems in user software. At least I hope even if there already cases that proof otherwise.
Post by Thomas D. Dean
When was the last time you did an Ubuntu dist-upgrade?
'sudo apt-get dist-upgrade'
An hour ago.
Post by Thomas D. Dean
The gcl from Ubuntu 16.04, seems to be
gcl
GCL (GNU Common Lisp) 2.6.12 CLtL1 Oct 29 2015 23:21:28
<snip>
This does not seem to be an ANSI gcl.
You can choose if you want to use ansi after doing a

sudo dpkg-reconfigure -plow gcl

But since creating a few empty files and directories seems to resolve the problem... ...maybe someone finds out where it comes from and will find something better than just adding a touch and three mkdir commands to Makefile.am.

My guess is that you downloaded the sources for an official maxima release from sourceforge (which comes with a few files the git version comes without) and "make distclean" doesn't delete these files as they are part of the tarball.

Kind regards,

Gunter.
Thomas D. Dean
2017-06-25 21:54:06 UTC
Permalink
Raw Message
Post by Gunter Königsmann
But since creating a few empty files and directories seems to resolve the problem... ...maybe someone finds out where it comes from and will find something better than just adding a touch and three mkdir commands to Makefile.am.
My guess is that you downloaded the sources for an official maxima release from sourceforge (which comes with a few files the git version comes without) and "make distclean" doesn't delete these files as they are part of the tarball.
Look at my email 06/24/2017 05:46 PM. I completely removed the
Post by Gunter Königsmann
Rm -Rf maxima-code
git clone git://git.code.sf.net/p/maxima/code maxima-code
cd maxima-code/
./bootstrap
./configure --enable-gcl
make -j12
sudo make install
/usr/local/bin/maxima
Tom Dean
Thomas D. Dean
2017-06-25 23:21:30 UTC
Permalink
Raw Message
On 06/25/2017 02:54 PM, Thomas D. Dean wrote:

This is getting somewhat over my head.

It looks like the script src/maxima is not made properly.

When it is created within the source tree, it has top_srcdir pointing in
the source tree. When it is created within the build tree, top_srcdir
point in the build tree
diff maxima ../../maxima-build/src
10c10
< MAXIMA_VERSION="branch_5_40_base_83_ged20729"
---
MAXIMA_VERSION="5.40post"
15c15
< top_srcdir=`unixize "/home/tomdean/Math/Maxima/maxima-code"`
---
top_srcdir=`unixize "/home/tomdean/Math/Maxima/maxima-build"`
To get to this point,
Rm -Rf maxima-code
git clone git://git.code.sf.net/p/maxima/code maxima-code
cd maxima-code/
./bootstrap
cd ..
rm -Rf maxima-build
mkdir maxima-build
cd maxima-build
../maxima-code/configure --enable-gcl
make -d
Leave the process hanging at the error so it does not clean up

In another xterm,
cd maxima-code
./configure --enable-gcl
make -d
now, the difference in the src/maxima script can be seen.

I believe the top_srcdir should be the same in both cases.

Where is this script created?

Tom Dean
Gunter Königsmann
2017-06-26 04:27:47 UTC
Permalink
Raw Message
Post by Thomas D. Dean
now, the difference in the src/maxima script can be seen.
I believe the top_srcdir should be the same in both cases.
Configure.ac tells make to autogenerate it => configure creates it from src/maxima.in.

Kind regards,

Gunter.
Post by Thomas D. Dean
Where is this script created?
Tom Dean
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Maxima-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/maxima-discuss
Thomas D. Dean
2017-06-25 22:09:49 UTC
Permalink
Raw Message
On 06/24/2017 05:46 PM, Thomas D. Dean wrote:

I build in the source tree. Again, read my earlier email.

Building outside the source tree has been broken for a long time.
mkdir maxima-build
cd maxima-build
../maxima-code/configure --enable-gcl
...
make
Making all in admin
make[1]: Entering directory '/home/tomdean/Math/Maxima/maxima-build/admin'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/tomdean/Math/Maxima/maxima-build/admin'
Making all in crosscompile-windows
make[1]: Entering directory
'/home/tomdean/Math/Maxima/maxima-build/crosscompile-windows'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory
'/home/tomdean/Math/Maxima/maxima-build/crosscompile-windows'
Making all in src
make[1]: Entering directory '/home/tomdean/Math/Maxima/maxima-build/src'
gcl -batch -eval '(progn (load
"../../maxima-code/lisp-utils/defsystem.lisp") (load
"../../maxima-code/lisp-utils/make-depends.lisp") (funcall (intern
"CREATE-DEPENDENCY-FILE" :mk) (list "binary-gcl/maxima"
"sys-proclaim.lisp") "gcl-depends.mk") )'

Warning: SIMPLE-WARNING: REQUIRE is being redefined.
...


Tom Dean
Gunter Königsmann
2017-06-26 05:12:37 UTC
Permalink
Raw Message
In other words: There are gcl installs that work fine and others
(perhaps due to a bugfix in gcl that didn't affect the version number,
there seem to have been at least 53 of these.) that fail to compile
maxima if a few directories and sys-proclaim.lisp are missing (or that
randomly fail and happen to succeed every time I manually create these
items. But in this case it would be interesting to know what makes even
single-process-builds non-deterministic.

Kind regards,

Gunter.
Thomas D. Dean
2017-06-26 20:07:04 UTC
Permalink
Raw Message
Post by Gunter Königsmann
In other words: There are gcl installs that work fine and others
(perhaps due to a bugfix in gcl that didn't affect the version number,
there seem to have been at least 53 of these.) that fail to compile
maxima if a few directories and sys-proclaim.lisp are missing (or that
randomly fail and happen to succeed every time I manually create these
items. But in this case it would be interesting to know what makes even
single-process-builds non-deterministic.
Have I been talking at cross purposes?? I have been addressing building
maxima with gcl

re GCL: ========================================

I use GCL 2.6.12 from the release tarball, gcl-2.6.12.tar.gz. Building
GCL from the release tarball works. I use:
./configure --enable-ansi --enable-readline

I think the GNU GCL build from git head has been broken for some time.
I searched, seems there is no bug report on this. I submitted one.

re MAXIMA: ======================================

As far as I can tell, the IN SOURCE TREE building maxima with the 2.6.12
GCL release always succeeds.

The out of source tree maxima with the same GCL build always fails.

Tom Dean

Loading...