--with-gmp
Ralf Hemmecke
sorry that I am a bit late, but I've just browsed through configure.ac.
It seems to me that this code is missing a check whether gmp is actually
installed.
http://www.gnu.org/software/gmp/manual/html_node/Autoconf.html
Also, I think FriCAS should rather use --enable-gmp. With --with-gmp I
would expect to be able to say something like
--with-gmp=/path/to/package/gmp.
In fact, thinking about this, maybe it should also be
--enable-algebra-optimization=...
because according to
http://www.gnu.org/software/autoconf/manual/html_node/External-Software.html#External-Software
it is --with-PACKAGENAME, but algebra-optimization is certainly not a
package.
Optimization is a compile-time feature.
http://www.gnu.org/software/autoconf/manual/html_node/Package-Options.html#Package-Options
Same with --enable-gmp. It is a feature which optimizes, but is not
really necessary.
Ralf
Waldek Hebisch
>
> Hello,
>
> sorry that I am a bit late, but I've just browsed through configure.ac.
> It seems to me that this code is missing a check whether gmp is actually
> installed.
>
True. I was thinking about good test and it looked that the best
test is to compile the actual file (src/lib/gmp_wrap.c). However,
since Makefiles are not ready at configure time we can not do
this in regular way. So I decided to postpone this -- I you
want to add test you are welcome.
> http://www.gnu.org/software/gmp/manual/html_node/Autoconf.html
>
> Also, I think FriCAS should rather use --enable-gmp. With --with-gmp I
> would expect to be able to say something like
> --with-gmp=/path/to/package/gmp.
>
Well, you should be able to say where to find GMP. Quite possible
that we will need to split '--with-gmp' into '--enable-gmp' and
'--with-gmp-library' and '--with-gmp-headers'. ATM the idea is
to get _some_ way to use GMP and figure out later which options
are useful.
> In fact, thinking about this, maybe it should also be
>
> --enable-algebra-optimization=...
>
> because according to
>
> http://www.gnu.org/software/autoconf/manual/html_node/External-Software.html#External-Software
>
> it is --with-PACKAGENAME, but algebra-optimization is certainly not a
> package.
>
> Optimization is a compile-time feature.
> http://www.gnu.org/software/autoconf/manual/html_node/Package-Options.html#Package-Options
>
> Same with --enable-gmp. It is a feature which optimizes, but is not
> really necessary.
>
You are right. However, GNU coding standards have rather rigid
view on some issues and real life is more fuzzy. Hence some
confusion which of 'enable' or 'with' to use. Note the following:
These options allow users to choose which optional features to build
and install. --enable-feature options should never make a feature behave
differently or cause one feature to replace another. They should only
cause parts of the program to be built rather than left out.
Algebra optimization definitely does not work as "parts of the program
to be built rather than left out" -- it changes behaviour. Also,
at build time '--with-gmp' causes extra code to be built, but at
run-time it causes replacement of sbcl routines by GMP ones.
BTW: I think it is not the first time where our usage does not
fit GNU standards...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> Ralf Hemmecke wrote:
>> sorry that I am a bit late, but I've just browsed through
>> configure.ac. It seems to me that this code is missing a check
>> whether gmp is actually installed.
> True. I was thinking about good test and it looked that the best
> test is to compile the actual file (src/lib/gmp_wrap.c). However,
> since Makefiles are not ready at configure time we can not do this in
> regular way. So I decided to postpone this -- I you want to add test
> you are welcome.
Done at
https://github.com/hemmecke/fricas/commit/7f3d90706378d535c6522eaf5229bcc45792e482
Actually, I have two other patches that switch from --with to --enable.
https://github.com/hemmecke/fricas/commit/126d08aae382254cabd61342973cf24a9420e623
https://github.com/hemmecke/fricas/commit/21faa0482484be49275ad6e423723446204be625
All these patches do not (yet) include a regeneration of "configure",
because I use autoconf 2.67 whereas Waldek usually uses 2.61.
Choose as you like.
>> Also, I think FriCAS should rather use --enable-gmp. With
>> --with-gmp I would expect to be able to say something like
>> --with-gmp=/path/to/package/gmp.
> Well, you should be able to say where to find GMP. Quite possible
> that we will need to split '--with-gmp' into '--enable-gmp' and
> '--with-gmp-library' and '--with-gmp-headers'. ATM the idea is to
> get _some_ way to use GMP and figure out later which options are
> useful.
I haven't yet done the --with-gmp-library and --with-gmp-header since I
don't yet know of the canonical way to do this. We are probably not the
first that want to configure for gmp. So I guess there should be
something reliable for this check somewhere in the web.
> You are right. However, GNU coding standards have rather rigid view
> on some issues and real life is more fuzzy. Hence some confusion
> which of 'enable' or 'with' to use. Note the following:
>
> These options allow users to choose which optional features to build
> and install. --enable-feature options should never make a feature
> behave differently or cause one feature to replace another. They
> should only cause parts of the program to be built rather than left
> out.
;-) Yep. That's the problems with rules, laws, and conventions. Real
life never fits perfectly.
My distinction, however, is between "feature" (--enable) and "package"
(--with). But you are right that the above quote makes it actually
impossible to --enable an optimization, since it changes behaviour.
> Also, at build time '--with-gmp' causes extra code to be built, but
> at run-time it causes replacement of sbcl routines by GMP ones.
Yes, that is a border case. ;-)
> BTW: I think it is not the first time where our usage does not fit
> GNU standards...
Not a big deal, I can live with either as long as it is check that gmp
is actually available.
Ralf
PS:
In order to get the patches...
Either
git clone git://github.com/hemmecke/fricas.git
cd fricas
git checkout configure-ac
git format-patch -3
Or if you already have a FriCAS git repo... (this variant is faster
since it doesn't download all of fricas again)
cd fricas
git remote add hemmecke git://github.com/hemmecke/fricas.git
git fetch hemmecke
git checkout configure-ac
git format-patch -3
Waldek Hebisch
> On 11/19/2010 07:17 PM, Waldek Hebisch wrote:
> > Ralf Hemmecke wrote:
> >> sorry that I am a bit late, but I've just browsed through
> >> configure.ac. It seems to me that this code is missing a check
> >> whether gmp is actually installed.
>
> > True. I was thinking about good test and it looked that the best
> > test is to compile the actual file (src/lib/gmp_wrap.c). However,
> > since Makefiles are not ready at configure time we can not do this in
> > regular way. So I decided to postpone this -- I you want to add test
> > you are welcome.
>
> Done at
>
> https://github.com/hemmecke/fricas/commit/7f3d90706378d535c6522eaf5229bcc45792e482
>
> Actually, I have two other patches that switch from --with to --enable.
>
> https://github.com/hemmecke/fricas/commit/126d08aae382254cabd61342973cf24a9420e623
>
> https://github.com/hemmecke/fricas/commit/21faa0482484be49275ad6e423723446204be625
>
> All these patches do not (yet) include a regeneration of "configure",
> because I use autoconf 2.67 whereas Waldek usually uses 2.61.
>
> Choose as you like.
>
Looks OK. Note that GMP test is not perfect: we absolutely need
_shared_ GMP, but AFAIU the test will pass if only static GMP
is installed.
Is using autoconf 2.61 a problem for you? If yes I will
commit.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> _shared_ GMP, but AFAIU the test will pass if only static GMP
> is installed.
Was interesting to realize that the test as described at
AC_CHECK_LIB(gmp, __gmpz_init)
actually seemed to check for the .so file and did not even check
existence of gmp.h.
I'll investigate again and commit.
> Is using autoconf 2.61 a problem for you? If yes I will
> commit.
Well, I'll install 2.61.
What is with
https://github.com/hemmecke/fricas/commit/126d08aae382254cabd61342973cf24a9420e623
and
https://github.com/hemmecke/fricas/commit/21faa0482484be49275ad6e423723446204be625
Do you like to rename from --with-... to --enable-... or rather leave it
as it is?
Ralf
Ralf Hemmecke
> _shared_ GMP, but AFAIU the test will pass if only static GMP
> is installed.
Only slightly related to the gmp test...
In Ubuntu there is now the following dependency:
http://packages.ubuntu.com/maverick/gcc
http://packages.ubuntu.com/maverick/cpp
http://packages.ubuntu.com/maverick/cpp-4.4
http://packages.ubuntu.com/maverick/libgmp3c2
If I temporarily remove all /usr/libgmp* files, then configure says:
checking build system type... i686-pc-linux
checking host system type... i686-pc-linux
checking target system type... i686-pc-linux
checking for make... make
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/hemmecke/scratch/build/fricas':
configure: error: C compiler cannot create executables
See `config.log' for more details
And the log says...
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "FriCAS"
| #define PACKAGE_TARNAME "fricas"
| #define PACKAGE_VERSION "2010-09-22"
| #define PACKAGE_STRING "FriCAS 2010-09-22"
| #define PACKAGE_BUGREPORT "fricas...@googlegroups.com"
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
So on Maverick the -lgmp test is actually somewhat superfluous.
Same for Debian Squeeze.
Ralf
PS: I'll try to find a machine where libgmp.a is installed and libgmp.so
isn't.
Ralf Hemmecke
> _shared_ GMP,
Why is that absolutely necessary? Because of SBCL? Or because you set up
the Makefile in such a way that it only builds gmp_wrap.so? Is there
really no way to make it working with libgmp.a?
> but AFAIU the test will pass if only static GMP is installed.
That's true as far as what I've tested now.
So if libgmp.a alone is useless, then I'd have to refine the test a bit.
I guess, I'd have to search LD_LIBRARY_PATH for the libgmp.so (after the
test, that I have already). Or is there any other variable I'd have to
check. I guess that might be platform dependent, right?
Ralf
Waldek Hebisch
>
> > Note that GMP test is not perfect: we absolutely need
> > _shared_ GMP,
>
> Why is that absolutely necessary? Because of SBCL? Or because you set up
> the Makefile in such a way that it only builds gmp_wrap.so? Is there
> really no way to make it working with libgmp.a?
>
AFAIK at runtime sbcl can only load shared libraries. Theoretically
only gmp_wrap.so needs to be shared library, but on most platforms
it requires shared GMP. To use static library we would need
sbcl sources and patch its build process to link to GMP at
build time ...
> > but AFAIU the test will pass if only static GMP is installed.
>
> That's true as far as what I've tested now.
>
> So if libgmp.a alone is useless, then I'd have to refine the test a bit.
>
> I guess, I'd have to search LD_LIBRARY_PATH for the libgmp.so (after the
> test, that I have already). Or is there any other variable I'd have to
> check. I guess that might be platform dependent, right?
>
What we really need is ability to compile a file using GMP header,
and link a shared library to GMP. This means that we need correct
compiler flags to force generation of shared library instead of
an executable. As I wrote, I found it hard to invent a test that
is significantly simpler than gmp_wrap.c...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> > Looks OK. Note that GMP test is not perfect: we absolutely need
> > _shared_ GMP, but AFAIU the test will pass if only static GMP
> > is installed.
>
> Only slightly related to the gmp test...
>
> In Ubuntu there is now the following dependency:
>
> http://packages.ubuntu.com/maverick/gcc
> http://packages.ubuntu.com/maverick/cpp
> http://packages.ubuntu.com/maverick/cpp-4.4
> http://packages.ubuntu.com/maverick/libgmp3c2
>
> If I temporarily remove all /usr/libgmp* files, then configure says:
>
> configure: error: C compiler cannot create executables
> So on Maverick the -lgmp test is actually somewhat superfluous.
> Same for Debian Squeeze.
Modern gcc uses gmp, so machine having gcc will also have
libgmp.so. But we still need to test for header files and
for ability to link to libgmp.so: it may happen that shared
library is present (and loadable at runtime) but data needed
for linking _new_ code to the shared library is missing.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> As I wrote, I found it hard to invent a test that
> is significantly simpler than gmp_wrap.c...
Well, you are basically right. I searched quite a lot, but was unable to
find something canonical or better.
What do you think about
https://github.com/hemmecke/fricas/commit/4d7641be61808ac1a18136924370057303059a15
Unfortunately, until now I was unable to find a machine that I can
control or which doesn't have gmp already installed. So I couldn't
really test the above patch. :-(
I'm currently experimenting with setting up a virtual machine ... Never
have done this before... so complete test may take a while.
Ralf
Waldek Hebisch
>
> Hi Waldek,
>
> > As I wrote, I found it hard to invent a test that
> > is significantly simpler than gmp_wrap.c...
>
> Well, you are basically right. I searched quite a lot, but was unable to
> find something canonical or better.
> What do you think about
>
> https://github.com/hemmecke/fricas/commit/4d7641be61808ac1a18136924370057303059a15
>
Looks OK -- should be good enough.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> Looks OK -- should be good enough.
Well, not quite. I had to add quotes. And I seemed to have an instance
where
if test ...; then ... fi
in configure.ac doesn't produce the same semantics as
AS_IF([test ...],[...])
Actually, the code in configure is the same, but in a different order
which seemingly made CPP undefined for the header file tests. :-(
See "configure-ac" branch at https://github.com/hemmecke/fricas/network
But now, I've installed Ubuntu Hardy in a virtual machine (VirtualBox).
Compilation with my configure.ac patches and --enable-gmp work fine.
I also only get 4 gmp warnings not 8 as Martin Baker reported at
http://groups.google.com/group/fricas-devel/msg/a818ee714ec34e1c
So I assume that everything worked out fine and gmp is enabled.
However...
)set messages time on
exp1()
digits(10^6)
pp1 := exp1();
reported 137 seconds. Well, maybe my 32bit laptop doesn't perform well
for that case and in a virtualbox.
But maybe something else is interesting.
For the above compilation I only had /usr/lib/libgmp.a. Interestingly,
my test for libgmp.a worked and Pippijn told me that for 32bit machines
libgmp.a might be enough.
I'll also test on a 64bit VM with Hardy later...
Ralf
hemmecke
an old OS I was unable to install a 64bit VM version of Hardy and thus
couldn't test how my patch behaves on a 64bit machine with just
gmp.h and libgmp.a installed. The test should fail, but I have no
machine where I can confirm this.
So if anyone has a machine where libgmp.so is not installed, but
libgmp.a is, can you please download trunk in revision 971, run
./configure and tell me the result.
Ralf
Ralf Hemmecke
http://groups.google.com/group/fricas-devel/msg/b4badd9e63f8f712?hl=en
I only had libgmp.a installed.
Without recompiling, if I put libgmp.so into /usr/lib and restart
fricas, then I see 8 warning messages and the exp1() with 10^6 digits
runs in 3.6 seconds.
Interestingly one seems to be able to switch on and off gmp by just
providing or not providing libgmp.so at runtime. I don't see any extra
error message if libgmp.* is not available at runtime.
Wouldn't it be a good idea (at least as long as gmp is not generally
standard in fricas) to show at the welcome screen (instead of the
warning messages) if GMP numbers are used or not?
Also, maybe if libgmp is available, a user should not have the need to
give --with-gmp at compile time but gmp should rather be enabled by
default. Any interest in a modification of configure.ac in this direction?
Ralf
Waldek Hebisch
When I renamed libgmp.so and friends (and used symlink from different
directory to make sure that gcc still can find libgmp.so) then on
my machine configure detected that GMP is missing. So the test
seem to work OK.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
> When I reported about 137 s runtime in
> http://groups.google.com/group/fricas-devel/msg/b4badd9e63f8f712?hl=en
> I only had libgmp.a installed.
>
> Without recompiling, if I put libgmp.so into /usr/lib and restart
> fricas, then I see 8 warning messages and the exp1() with 10^6 digits
> runs in 3.6 seconds.
>
> Interestingly one seems to be able to switch on and off gmp by just
> providing or not providing libgmp.so at runtime. I don't see any extra
> error message if libgmp.* is not available at runtime.
Yes, this is advantege of dynamic loading: the same binary can
use a library if present but still work if absent. This is
important for distributing binaries, otherwise we would need
to ship libgmp.so (tricky, because GMP uses instructions available
only on some models) or provide several tarballs.
> Wouldn't it be a good idea (at least as long as gmp is not generally
> standard in fricas) to show at the welcome screen (instead of the
> warning messages) if GMP numbers are used or not?
Yes, good idea.
> Also, maybe if libgmp is available, a user should not have the need to
> give --with-gmp at compile time but gmp should rather be enabled by
> default. Any interest in a modification of configure.ac in this direction?
ATM GMP support should be off by default because if something
related to detection of GMP fails it can easily break build.
Also, currently GMP support is unlikely to work on 64-bit
machines different that AMD64 (Intel = Amd). On other machines
it is good chance that it will work, but we will not know before
somebody actually tries... Assuming that there are no problems
we probably could make using GMP default on Intel/Amd machines
for next release.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
> https://github.com/hemmecke/fricas/commit/126d08aae382254cabd61342973cf24a9420e623
> and
> https://github.com/hemmecke/fricas/commit/21faa0482484be49275ad6e423723446204be625
> Do you like to rename from --with-... to --enable-... or rather leave it
> as it is?
>
Yes, please commit.
--
Waldek Hebisch
heb...@math.uni.wroc.pl