reduce-algebra-developers — Discussion of development, administration and support for Reduce

Re: [Reduce-algebra-developers] How to change the prompt in csl reduce?

[Arthur N. <ac...@ca...>]

On Sun, 29 Jan 2012, Andrey G. Grozin wrote:

> Hello *,
>
> In psl reduce I can do
>
> ------------------------------------------------
> grozin@elrond ~/reduce-1535/bin $ ./redpsl
> Reduce (Free PSL version), 21-Dec-2011 ...
>
> 1: lisp$
>
> 2* copyd('setpchar!-orig,'setpchar)$
>
> 3* procedure setpchar!-my(c);
> 3* begin scalar w;
> 3*     w:=setpchar!-orig(c);
> 3*     promptstring!*:="xx ";
> 3*     return w
> 3* end$
>
> 4* copyd('setpchar,'setpchar!-my)$
> *** Function `setpchar' has been redefined
>
> xx bye;
>
> Quitting
> grozin@elrond ~/reduce-1535/bin $
> ------------------------------------------------
>
> In csl reduce this does not work:
>
> ------------------------------------------------
> grozin@elrond ~/reduce-1535/bin $ ./redcsl -w
> Reduce (Free CSL version), 21-Dec-11 ...
>
> 1: lisp$
>
> 2* copyd('setpchar!-orig,'setpchar)$
>
> 3* procedure setpchar!-my(c);
> 3* begin scalar w;
> 3*     w:=setpchar!-orig(c);
> 3*     promptstring!*:="xx ";
> 3*     return w
> 3* end$
>
> 4* copyd('setpchar,'setpchar!-my)$
>
> 5* bye;
> grozin@elrond ~/reduce-1535/bin $
> ------------------------------------------------
>
> Is there some equivalent trick for csl reduce? It seems that libreduce.red 
> and redfront.red use something similar for both psl and csl, e.g.
>
> if redfront_pslp() then
>   copyd('setpchar,'redfront_setpchar!-psl)
> else
>   copyd('setpchar,'redfront_setpchar!-csl);
>
> but I don't see how to make it work in csl.
>
> Andrey
>

Your problem is that you are acting as if a variable called promptstring!* 
has some special meaning. In PSL I guess that that is what actually 
controls prompts, but in CSL it really is the setpchar function that 
changes what prompts are generated, so the line you have that goes 
"promptstring := "xx ";" has no useful effect at all. If you go
setpchar!-orig "xx "; instead you may get what you want.

I note that several packages clobber setpchar in the sort of way you are 
trying to - certainly libreduce, redfront and tmprint. The places where I 
can see it used from older code are in misc/cedit (never used these 
days???), rlisp/inter.red and rlisp/superv.red (the "real" places where 
Reduce as such decides what prompt it wants to display). I rather wonder 
whether some good generic change in rlisp/inter.red and rlisp/superv.red 
could provide a clean generic hook for people like you to use that did not 
involve redefining functions and risks of delving down below the level of 
abstaction there CSL and PSL had come to agreement?

Arthur

[Reduce-algebra-developers] How to change the prompt in csl reduce?

[Andrey G. G. <A.G...@in...>]

Hello *,

In psl reduce I can do

------------------------------------------------
grozin@elrond ~/reduce-1535/bin $ ./redpsl
Reduce (Free PSL version), 21-Dec-2011 ...

1: lisp$

2* copyd('setpchar!-orig,'setpchar)$

3* procedure setpchar!-my(c);
3* begin scalar w;
3*     w:=setpchar!-orig(c);
3*     promptstring!*:="xx ";
3*     return w
3* end$

4* copyd('setpchar,'setpchar!-my)$
*** Function `setpchar' has been redefined

xx bye;

Quitting
grozin@elrond ~/reduce-1535/bin $
------------------------------------------------

In csl reduce this does not work:

------------------------------------------------
grozin@elrond ~/reduce-1535/bin $ ./redcsl -w
Reduce (Free CSL version), 21-Dec-11 ...

1: lisp$

2* copyd('setpchar!-orig,'setpchar)$

3* procedure setpchar!-my(c);
3* begin scalar w;
3*     w:=setpchar!-orig(c);
3*     promptstring!*:="xx ";
3*     return w
3* end$

4* copyd('setpchar,'setpchar!-my)$

5* bye;
grozin@elrond ~/reduce-1535/bin $
------------------------------------------------

Is there some equivalent trick for csl reduce? It seems that libreduce.red 
and redfront.red use something similar for both psl and csl, e.g.

if redfront_pslp() then
    copyd('setpchar,'redfront_setpchar!-psl)
else
    copyd('setpchar,'redfront_setpchar!-csl);

but I don't see how to make it work in csl.

Andrey

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[Arthur N. <ac...@ca...>]

> I've attached the config.log from the fox directory for your perusal.
>

Your previous email reported errors that contained the text "4.2", as in

"It builds on lion, but with the following errors:

:info:configure configure: Building for Macintosh/Darwin with X
:info:configure llvm-gcc-4.2: error trying to exec
'/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': 
execvp:
No such file or directory
:info:configure lipo: can't figure out the architecture type of:
/var/tmp//ccAr5REE.out
:info:configure llvm-gcc-4.2: error trying to exec"

while the one you have now sent us all does not show any mention of 
llvm-gc-4.2 at all, and looks pretty reasonable to me (apart from the 
fact that I can not promise that CSL will build effortlessly with any C 
compiler other than the one that GNU autotools automatically select, i.e. 
gcc, since I have not personally tested all other variants). So at the 
level of the CSL/Reduce configure script for FOX I do not see evidence 
here of an issue!

With regard to the bulk of the whole of the subversion repository for 
Reduce, yes it is now quite big. If you do not use CSL at all (ie you are 
just fetching for PSL) you can obviously just not fetch the csl directory 
and save a LOT. Specifically csl/support-packages contains code that you 
will not actually use during the build but is included to try to be extra 
careful that (L)GPL rights holders are kept content, and some things that 
are not even (L)GPL but are nevertheless imported from elsewhere are put 
there for reference and politeness so that people can see the original 
form of them. The README.* files there are intended to comment on 
provenance and licencing. An individual who is just building Reduce but 
does not intent to redistribute it does not need any of that 80 Mbytes!

Similarly when building just for CSL you do not need the 30+ Mbytes of PSL 
stuff. And in neither case would jlisp or jslisp be needed. I am supposing 
you would only fetch "trunk" and so will avoid the bulky historical 
archives.

Might I suggest that if you ever try sending bulky log files you send them 
just to me not to the whole newsgroup since there is a limit to the size 
of attachment that is automatically accepted there.

I have a Mac with 10.7 on it - although by and large I do not find it by 
any means my favourite machine, and I generally do not enjoy development 
on that platform. But if there is a really easy recipe you can provide me 
with and your most current set of scripts and you believe that with VERY 
LITTLE EFFORT and no special magical background I could try running your 
script so I can see its behaviour directly that might let me find out what 
is going on better.  But note that I do NOT use the Xcode gui or anything 
other than a command line on a Mac when I do development there, and I do 
not want to. And I have NEVER used Macports before and can not be assumed 
to be willing to spend a lot of time readings its documentation and 
understanding it!

              Arthur

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 9, 2012, at 6:49 AM, Arthur Norman wrote:

> On Sun, 8 Jan 2012, mark brethen wrote:
>> An update to my previous post:
>> 
>> Macports handles the configure and build phases; all that needs to be 
> passed are the arguments, it handles all the environment variables. One 
> drawback is that I can't pass both --with-csl and --with-psl. So I had to 
> override macports' configure phase. At first, I used:
>> 
>> configure {
>> system -W ${worksrcpath} "./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"
>> }
>> 
> 
> As regards this I might note that the CSL and PSL variants of Reduce are 
> for almost all purposes ALTERNATIVES rather than being things where 
> installing one should automatically install the other. I guess there are 
> three sorts of people in the world:
> (1) Developers who are not just keen on getting their Reduce package in 
> good condition, but who wish to be properly careful that the code involved 
> is compatible with both the CSL and the PSL-supported variants. Of all the 
> people who download and install Reduce I believe these count as a tiny 
> minority.
> (2) General users. They only need EITHER the PSL or the CSL based version 
> of Reduce. Installing both just clutters up their disc space, makes the 
> installation process slower and in general causes confusion! There is of 
> course a potential uncertainty as to which to choose, but even if theyu 
> install both to start with after a while tidiness will cause them to 
> de-install the one that does not suit them.
> (3) Extreme users. Some (but ony a VERY FEW) users will be trying 
> calculations so large that they fail on one or other version. Or they may 
> trigger a bug in one or other version, or performance may differ enough to 
> be critical. These people may want both versions installed so thay can 
> switch between them as thay hit issues. Again I believe these are a tiny 
> (but obviosuly important) minority.
> 
> So I might have expected that one Macport package for the CSL and one for 
> the PSL version would be more use for customers as well as less strain for 
> you.
> 
I've already had a lengthy discussion on the macports-dev list about subports, variants, 
or everything in one port. subports is probably the way to go, if it was desired to have 
separately installable ports and avoid duplicate scripting. The only disadvantage is the 
svn source, which is around 370MB, which would have to be checked out from the 
project's repository each time. Macports currently archives only tarball dists, but there
is an open ticket to resolve this. 

> 
> Your extract showing "errors" is in fact not terribly helpful to me even 
> if I wanted to check it! It does not provide context. Is this an extract 
> from a config.log? You will be aware that configure does all sorts of 
> things that cause "errors" in that when it is checking for the 
> availability of something it tries using it, and if the attempt does or 
> does not succeed it sets its various flags. So from what you send I can 
> not tell if the messages you send are merely the normal process of 
> configuration when it checks to see if llvm-gcc-4.2 is installed as one of 
> the possible compilers of interest, or of it is an Error with a capital 
> letter. In general when configure is run and something fails one looks in 
> config.log and can see the exact command that was invoked and the contents 
> of the file that was being presented for compilation. It is lengthy and 
> messy and you need (as I say) to distinguish between compilations that 
> fail merely incidentally because they are checking for some (optional) 
> feature that is not present on the machine concerned, and errors that are 
> indications of true disaster.
> 
I've attached the config.log from the fox directory for your perusal.

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[Arthur N. <ac...@ca...>]

On Sun, 8 Jan 2012, mark brethen wrote:
> An update to my previous post:
>
> Macports handles the configure and build phases; all that needs to be 
passed are the arguments, it handles all the environment variables. One 
drawback is that I can't pass both --with-csl and --with-psl. So I had to 
override macports' configure phase. At first, I used:
>
> configure {
>  system -W ${worksrcpath} "./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"
> }
>

As regards this I might note that the CSL and PSL variants of Reduce are 
for almost all purposes ALTERNATIVES rather than being things where 
installing one should automatically install the other. I guess there are 
three sorts of people in the world:
(1) Developers who are not just keen on getting their Reduce package in 
good condition, but who wish to be properly careful that the code involved 
is compatible with both the CSL and the PSL-supported variants. Of all the 
people who download and install Reduce I believe these count as a tiny 
minority.
(2) General users. They only need EITHER the PSL or the CSL based version 
of Reduce. Installing both just clutters up their disc space, makes the 
installation process slower and in general causes confusion! There is of 
course a potential uncertainty as to which to choose, but even if theyu 
install both to start with after a while tidiness will cause them to 
de-install the one that does not suit them.
(3) Extreme users. Some (but ony a VERY FEW) users will be trying 
calculations so large that they fail on one or other version. Or they may 
trigger a bug in one or other version, or performance may differ enough to 
be critical. These people may want both versions installed so thay can 
switch between them as thay hit issues. Again I believe these are a tiny 
(but obviosuly important) minority.

So I might have expected that one Macport package for the CSL and one for 
the PSL version would be more use for customers as well as less strain for 
you.


> but I didn't realize that by overriding macports configure, the 
environment variables didn't get passed (as seen in macports' log):
>
> :info:configure in-place build attempt = yes
> :info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl'
> :info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
> :info:configure configure: +++ Will build in /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/cslbuild/x86_64-mac_10.7_lion-darwin11.2.0
> :info:configure configure: passcc =
> :info:configure configure: doconfig = /bin/sh /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/configure  '--prefix=/opt/local' '--with-csl'    CPPFLAGS="" CFLAGS=""             CXXFLAGS="" LDFLAGS=""              --with-build="x86_64-mac_10.7_lion-darwin11.2.0" --with-pslbuild="x86_64-mac_10.7_lion-darwin11.2.0"
> :info:configure configure: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
> :info:configure checking build system type... x86_64-apple-darwin11.2.0
> :info:configure checking host system type... x86_64-apple-darwin11.2.0
> :info:configure in-place build attempt = no
> :info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl' 'CPPFLAGS=' 'CFLAGS=' 'CXXFLAGS=' 'LDFLAGS=' '--with-build=x86_64-mac_10.7_lion-darwin11.2.0' '--with-pslbuild=x86_64-mac_10.7_lion-darwin11.2.0'
> :info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
> :info:configure configure: +++ standard build case, srcdir = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
>
> Amazingly, this compiled on lion, but did not for the fellow who had 
that script on his 10.6 machine. So I added the variables like so:
>
> configure {
>  system -W ${worksrcpath} \
>     "CC=${configure.cc} \
>      CFLAGS=\"${configure.cflags} [get_canonical_archflags cc]\" \
>      CXX=${configure.cxx} \
>      CXXFLAGS=\"${configure.cxxflags} [get_canonical_archflags cxx]\" \
>      CPPFLAGS=\"${configure.cppflags}\" \
>      LDFLAGS=\"${configure.ldflags} [get_canonical_archflags ld]\" \
>      ./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"
> }
>
> Now the correct environment is set, as you can see:
>
> :info:configure configure: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
> :info:configure checking build system type... x86_64-apple-darwin11.2.0
> :info:configure checking host system type... x86_64-apple-darwin11.2.0
> :info:configure in-place build attempt = yes
> :info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl'
> :info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
> :info:configure configure: +++ Will build in /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/cslbuild/x86_64-mac_10.7_lion-darwin11.2.0
> :info:configure configure: passcc = CC="/Developer/usr/bin/clang" CPP="" CXX="/Developer/usr/bin/clang++" CXXCPP=""
> :info:configure configure: doconfig = /bin/sh /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/configure  '--prefix=/opt/local' '--with-csl'    CPPFLAGS="-I/opt/local/include" CFLAGS="-O2 -arch x86_64"             CXXFLAGS="-O2 -arch x86_64" LDFLAGS="-L/opt/local/lib -arch x86_64"             CC="/Developer/usr/bin/clang" CPP="" CXX="/Developer/usr/bin/clang++" CXXCPP="" --with-build="x86_64-mac_10.7_lion-darwin11.2.0" --with-pslbuild="x86_64-mac_10.7_lion-darwin11.2.0"
> :info:configure configure: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
> :info:configure checking build system type... x86_64-apple-darwin11.2.0
> :info:configure checking host system type... x86_64-apple-darwin11.2.0
> :info:configure in-place build attempt = no
> :info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl' 'CPPFLAGS=-I/opt/local/include' 'CFLAGS=-O2 -arch x86_64' 'CXXFLAGS=-O2 -arch x86_64' 'LDFLAGS=-L/opt/local/lib -arch x86_64' 'CC=/Developer/usr/bin/clang' 'CPP=' 'CXX=/Developer/usr/bin/clang++' 'CXXCPP=' '--with-build=x86_64-mac_10.7_lion-darwin11.2.0' '--with-pslbuild=x86_64-mac_10.7_lion-darwin11.2.0'
> :info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
> :info:configure configure: +++ standard build case, srcdir = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
>
> It builds on lion, but with the following errors:
>
> :info:configure configure: Building for Macintosh/Darwin with X
> :info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
> :info:configure lipo: can't figure out the architecture type of: /var/tmp//ccAr5REE.out
> :info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
> :info:configure conftest.c:1:19: error: stdio.h: No such file or directory
> :info:configure conftest.c: In function 'main':
> :info:configure conftest.c:3: warning: incompatible implicit declaration of built-in function 'printf'
> :info:configure lipo: can't figure out the architecture type of: /var/tmp//ccjtXcMt.out
> :info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
> :info:configure conftest.c:1:19: error: stdio.h: No such file or directory
> :info:configure conftest.c: In function 'main':
> :info:configure conftest.c:3: warning: incompatible implicit declaration of built-in function 'printf'
> :info:configure lipo: can't figure out the architecture type of: /var/tmp//ccD75kI3.out
> :info:configure configure: fat binary creation will probably NOT be possible
>
>
> These errors were in the previous log as well. I don't know if this is 
because those instructions work for a 10.6 installation, but not 10.7? 
And there's still those explicit "gcc" calls, as I pointed out in my 
previous message.

Your extract showing "errors" is in fact not terribly helpful to me even 
if I wanted to check it! It does not provide context. Is this an extract 
from a config.log? You will be aware that configure does all sorts of 
things that cause "errors" in that when it is checking for the 
availability of something it tries using it, and if the attempt does or 
does not succeed it sets its various flags. So from what you send I can 
not tell if the messages you send are merely the normal process of 
configuration when it checks to see if llvm-gcc-4.2 is installed as one of 
the possible compilers of interest, or of it is an Error with a capital 
letter. In general when configure is run and something fails one looks in 
config.log and can see the exact command that was invoked and the contents 
of the file that was being presented for compilation. It is lengthy and 
messy and you need (as I say) to distinguish between compilations that 
fail merely incidentally because they are checking for some (optional) 
feature that is not present on the machine concerned, and errors that are 
indications of true disaster.



I have just checked in a new set of configure files. If the person who 
invoked configure does so with CC or CXX set (to values other than gcc and 
g++) then it skips the Mac code that uses gcc explicitly and tries to
identity which SDK is available. The reasoning there is that if anybody is
going to force selection of some particular C compiler then it becomes 
THEIR responsibility to force in values of CFLAGS, LDFLAGS, LIBS and 
anything else that could matter, including special flags to select an SDK 
or a word length.

That I think purs responsibility more clearly where it has to lie! I hope 
I got my changes correct - let me know if I messed up!!!


>
> -Mark

Arthur

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 8, 2012, at 10:35 AM, Arthur Norman wrote:

> I my Mac tests I have had significant pain with the 10.7 SDK (hence the
> "--without-lionSDK" option that the configure scripts support (on the CSL 
> side)) because of changes that Apple had made. Thus even on Lion I 
> typically build with the Snow Leopard SDK.

An update to my previous post:

Macports handles the configure and build phases; all that needs to be passed are the arguments, it handles all the environment variables. One drawback is that I can't pass both --with-csl and --with-psl. So I had to override macports' configure phase. At first, I used:

configure {
  system -W ${worksrcpath} "./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"
}

but I didn't realize that by overriding macports configure, the environment variables didn't get passed (as seen in macports' log):

:info:configure in-place build attempt = yes
:info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl'
:info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
:info:configure configure: +++ Will build in /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/cslbuild/x86_64-mac_10.7_lion-darwin11.2.0
:info:configure configure: passcc = 
:info:configure configure: doconfig = /bin/sh /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/configure  '--prefix=/opt/local' '--with-csl'    CPPFLAGS="" CFLAGS=""             CXXFLAGS="" LDFLAGS=""              --with-build="x86_64-mac_10.7_lion-darwin11.2.0" --with-pslbuild="x86_64-mac_10.7_lion-darwin11.2.0"
:info:configure configure: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
:info:configure checking build system type... x86_64-apple-darwin11.2.0
:info:configure checking host system type... x86_64-apple-darwin11.2.0
:info:configure in-place build attempt = no
:info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl' 'CPPFLAGS=' 'CFLAGS=' 'CXXFLAGS=' 'LDFLAGS=' '--with-build=x86_64-mac_10.7_lion-darwin11.2.0' '--with-pslbuild=x86_64-mac_10.7_lion-darwin11.2.0'
:info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
:info:configure configure: +++ standard build case, srcdir = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk

Amazingly, this compiled on lion, but did not for the fellow who had that script on his 10.6 machine. So I added the variables like so:

configure {
  system -W ${worksrcpath} \
     "CC=${configure.cc} \
      CFLAGS=\"${configure.cflags} [get_canonical_archflags cc]\" \
      CXX=${configure.cxx} \
      CXXFLAGS=\"${configure.cxxflags} [get_canonical_archflags cxx]\" \
      CPPFLAGS=\"${configure.cppflags}\" \
      LDFLAGS=\"${configure.ldflags} [get_canonical_archflags ld]\" \
      ./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"
}

Now the correct environment is set, as you can see:

:info:configure configure: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
:info:configure checking build system type... x86_64-apple-darwin11.2.0
:info:configure checking host system type... x86_64-apple-darwin11.2.0
:info:configure in-place build attempt = yes
:info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl'
:info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
:info:configure configure: +++ Will build in /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/cslbuild/x86_64-mac_10.7_lion-darwin11.2.0
:info:configure configure: passcc = CC="/Developer/usr/bin/clang" CPP="" CXX="/Developer/usr/bin/clang++" CXXCPP=""
:info:configure configure: doconfig = /bin/sh /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk/configure  '--prefix=/opt/local' '--with-csl'    CPPFLAGS="-I/opt/local/include" CFLAGS="-O2 -arch x86_64"             CXXFLAGS="-O2 -arch x86_64" LDFLAGS="-L/opt/local/lib -arch x86_64"             CC="/Developer/usr/bin/clang" CPP="" CXX="/Developer/usr/bin/clang++" CXXCPP="" --with-build="x86_64-mac_10.7_lion-darwin11.2.0" --with-pslbuild="x86_64-mac_10.7_lion-darwin11.2.0"
:info:configure configure: Absolute path to source directory = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk
:info:configure checking build system type... x86_64-apple-darwin11.2.0
:info:configure checking host system type... x86_64-apple-darwin11.2.0
:info:configure in-place build attempt = no
:info:configure configure: host=x86_64-apple-darwin11.2.0 args= '--prefix=/opt/local' '--with-csl' 'CPPFLAGS=-I/opt/local/include' 'CFLAGS=-O2 -arch x86_64' 'CXXFLAGS=-O2 -arch x86_64' 'LDFLAGS=-L/opt/local/lib -arch x86_64' 'CC=/Developer/usr/bin/clang' 'CPP=' 'CXX=/Developer/usr/bin/clang++' 'CXXCPP=' '--with-build=x86_64-mac_10.7_lion-darwin11.2.0' '--with-pslbuild=x86_64-mac_10.7_lion-darwin11.2.0'
:info:configure configure: Will build in the x86_64-mac_10.7_lion-darwin11.2.0 subdirectory
:info:configure configure: +++ standard build case, srcdir = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk = /opt/local/var/macports/build/_Users_marbre_ports_math_reduce/reduce/work/trunk

It builds on lion, but with the following errors:

:info:configure configure: Building for Macintosh/Darwin with X
:info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
:info:configure lipo: can't figure out the architecture type of: /var/tmp//ccAr5REE.out
:info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
:info:configure conftest.c:1:19: error: stdio.h: No such file or directory
:info:configure conftest.c: In function 'main':
:info:configure conftest.c:3: warning: incompatible implicit declaration of built-in function 'printf'
:info:configure lipo: can't figure out the architecture type of: /var/tmp//ccjtXcMt.out
:info:configure llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
:info:configure conftest.c:1:19: error: stdio.h: No such file or directory
:info:configure conftest.c: In function 'main':
:info:configure conftest.c:3: warning: incompatible implicit declaration of built-in function 'printf'
:info:configure lipo: can't figure out the architecture type of: /var/tmp//ccD75kI3.out
:info:configure configure: fat binary creation will probably NOT be possible


These errors were in the previous log as well. I don't know if this is because those instructions work for a 10.6 installation, but not 10.7? And there's still those explicit "gcc" calls, as I pointed out in my previous message. 



-Mark

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 8, 2012, at 10:35 AM, Arthur Norman wrote:

> You are leaving me very confused about whether you are looking at a CSL 
> or a PSL build of Reduce. Please note that I am probably the main contact 
> for CSL stuff, but when it gets down to the innards of PSL it will be 
> others.

I'm trying to make sense of this myself. Please understand that I have very little
knowledge of C, so what I thought would be a simple macports tcl script to install 
your software, has turned out to be anything but :-) 

I set up the macports install script similar to the debian rules and install both csl and psl, i.e.

system -W ${worksrcpath} "./configure --prefix=${prefix} --with-csl ; ./configure --with-psl"

make

I have a lion (10.7) machine and was able to install both. On the 10.6 machine both failed
(Xport needs to compile first before downloading the psl binaries). I suspect as a result of that script.

> 
>> 
>> The larger issue is the fact that the sdk was not found, because of this script.
>> For instance, in .../trunk/csl/fox/configure.ac I found these lines:
>> 
> FOX is ONLY wanted or used or even investigated at all in the case that 
> you are building a CSL version.
> 
>> if gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch ix86_64 conftest.c -o conftest > /dev/null 2>&1
>> then
>>  AC_MSG_NOTICE([x96_64 binary creation will probably be possible using 10.7])
>>  else
>>    AC_MSG_ERROR([Need MACOSX SDK version 10.6 or 10.7])
>>  fi
>> fi
>> 
> 
> The code *I* see in csl/fox/configure.in reads (well lines have got 
> truncated a bit, but you can see...). There is NO fox/configure.ac, just a 
> configure.in.
> 
>     if test "x$with_lionSDK" != "xno" &&
>        gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch i386 -arch x86_64 con
>     then
>       AC_MSG_NOTICE("Macintosh x86_64 binaries via 10.7")
> #     enable_dependency_tracking="no"
>       archflags="-arch x86_64 "
>     else
>       if gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 conftest.c -
>       then
>         AC_MSG_NOTICE("Macintosh x86_64 binaries via 10.6")
> #       enable_dependency_tracking="no"
>         archflags="-arch x86_64 "
>       else
> #--     if gcc -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch ppc -arch i386 -a
> #--     then
> #--       AC_MSG_NOTICE("Macintosh fat binaries via 10.5")
> #--       enable_dependency_tracking="no"
> #--       archflags="-arch ppc -arch i386 -arch x86_64"
> #--     else
>         ...
> where the commented out bit at the end is looking for 10.5, 10.4, ... 
> versions of the SDK.
> 
> That means I can not match your query up with reality as I see it in the 
> latest trunk sources on sourceforge.

> 
>> any explicit "gcc" calls get rerouted by that script and return error.
>   There may
>> be others in your code, but I haven't looked at them all.
>> 
> 
> So can you please explain to me, as to one who is just plain confused but 
> has maybe missed something, just what sources you are using, and if thay 
> are not the current ones we are maintaining why not.

I used svn r1535, and you're correct, it was my mistake, I meant /trunk/csl/configure.ac. 
I've been looking through so many directories, that I got them confused.
However any instance of an explicit "gcc" call will get rerouted by that script.

> 
> 
> Sorry if I am being obtuse, but your query really looks ODD to me and that 
> makes it a LOT harder for me to know how to help.
> 
> Do I understand that your colleague installs a script names "gcc" that is 
> on his PATH ahead of the regular standard Mac compiler, and that does not 
> behave like ordinary gcc and that THAT is what is causing his macports 
> attempts to fail? Again that sounds WEIRD to me if I have understood it 
> correctly.
> 
The individual who tested the portfile on 10.6 is affiliated with macports and is using
the script referenced in the wiki link I provided. The intent of that script is
to return an error if a program explicity calls "gcc" instead of setting gcc to the
default. 

> I my Mac tests I have had significant pain with the 10.7 SDK (hence the
> "--without-lionSDK" option that the configure scripts support (on the CSL 
> side)) because of changes that Apple had made. Thus even on Lion I 
> typically build with the Snow Leopard SDK.

That was the first instance I found where "gcc" was called explicity. If you used the
explicit call "gcc" to locate the 10.6 SDK, that would also fail. I was told 'a raw reference 
to "gcc" will result in an error, since macports _never_ uses just "gcc"'

I hope this makes enough sense.

> 
> 
>          Arthur
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers


-Mark

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[Arthur N. <ac...@ca...>]

You are leaving me very confused about whether you are looking at a CSL 
or a PSL build of Reduce. Please note that I am probably the main contact 
for CSL stuff, but when it gets down to the innards of PSL it will be 
others.

>
> The larger issue is the fact that the sdk was not found, because of this script.
> For instance, in .../trunk/csl/fox/configure.ac I found these lines:
>
FOX is ONLY wanted or used or even investigated at all in the case that 
you are building a CSL version.

> if gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch ix86_64 conftest.c -o conftest > /dev/null 2>&1
> then
>   AC_MSG_NOTICE([x96_64 binary creation will probably be possible using 10.7])
>   else
>     AC_MSG_ERROR([Need MACOSX SDK version 10.6 or 10.7])
>   fi
> fi
>

The code *I* see in csl/fox/configure.in reads (well lines have got 
truncated a bit, but you can see...). There is NO fox/configure.ac, just a 
configure.in.

     if test "x$with_lionSDK" != "xno" &&
        gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch i386 -arch x86_64 con
     then
       AC_MSG_NOTICE("Macintosh x86_64 binaries via 10.7")
#     enable_dependency_tracking="no"
       archflags="-arch x86_64 "
     else
       if gcc -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch x86_64 conftest.c -
       then
         AC_MSG_NOTICE("Macintosh x86_64 binaries via 10.6")
#       enable_dependency_tracking="no"
         archflags="-arch x86_64 "
       else
#--     if gcc -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch ppc -arch i386 -a
#--     then
#--       AC_MSG_NOTICE("Macintosh fat binaries via 10.5")
#--       enable_dependency_tracking="no"
#--       archflags="-arch ppc -arch i386 -arch x86_64"
#--     else
         ...
where the commented out bit at the end is looking for 10.5, 10.4, ... 
versions of the SDK.

That means I can not match your query up with reality as I see it in the 
latest trunk sources on sourceforge.

> any explicit "gcc" calls get rerouted by that script and return error.
   There may
> be others in your code, but I haven't looked at them all.
>

So can you please explain to me, as to one who is just plain confused but 
has maybe missed something, just what sources you are using, and if thay 
are not the current ones we are maintaining why not.

Sorry if I am being obtuse, but your query really looks ODD to me and that 
makes it a LOT harder for me to know how to help.

Do I understand that your colleague installs a script names "gcc" that is 
on his PATH ahead of the regular standard Mac compiler, and that does not 
behave like ordinary gcc and that THAT is what is causing his macports 
attempts to fail? Again that sounds WEIRD to me if I have understood it 
correctly.

I my Mac tests I have had significant pain with the 10.7 SDK (hence the
"--without-lionSDK" option that the configure scripts support (on the CSL 
side)) because of changes that Apple had made. Thus even on Lion I 
typically build with the Snow Leopard SDK.


          Arthur

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 8, 2012, at 5:32 AM, Rainer Schöpf wrote:

> Hello Mark,
> 
>> "uname -p" returns the architecture of the kernel. On an Intel Mac that could 
>> be i386 or x86_64, depending on what kernel your Mac uses. There are 32-bit 
>> Macs (like the original MacBookPro1,1) that use the 32-bit kernel, there are 
>> 64-bit Macs (MacBookPro3,1) that use the 32-bit kernel, and there are more 
>> modern 64-bit Macs that use the 64-bit kernel. The bitness of the kernel is 
>> not an indication of the architecture of programs the computer can run.
>> 
>> I've been discussing this with the folks at MacPorts as well. They like 
>> programs to make no attempt at all to determine what architecture of programs 
>> they can run, and would prefer programs to rely on the CFLAGS, CXXFLAGS, 
>> LDFLAGS etc. variables in which we instruct the compiler for what 
>> architecture to build. (I'm not making any requests here, only giving you 
>> background info).
>> 
>> The macports individual who tested my install script on snow leopard, had his 
>> own script to detect whether a config/make file is using ${configure.cc} 
>> instead of running "gcc" explicitly. When your config tried to determine 
>> whether the C preprocessor defines the symbol __LP64__ the aforementioned 
>> script was found instead, producing the error.
> 
> Allow me to point out again that the config.guess script that tries to determine 
> whether the C preprocessor defines the symbol __LP64__ (and from which I quoted 
> some lines in an earlier mail message) is not part of the Reduce subversion 
> repository.  It is actually generated automatically by GNU automake as part of 
> the build process.
> 
> I don't have a Mac, so I can only do an educated guess on what is causing the 
> problem.  If config.guess is indeed the cause, then this is not specific to 
> Reduce, but may appear for any other program that relies on automake/autoconf.
> 
> On the other hand, it may well be that config.guess is doing what it should, but 
> that there is an interaction with another part of the Reduce build process. 
> 

I agree. It sounds like his machine may be 64-bit that uses the 32-bit kernel. 
On my lion (10.7) machine, unam -p returned i386 but it built x86_64.

> So, this person's using his own script is a standard method, or rather not?  
> Because if it isn't "standard" in the sense that it plays well together with GNU 
> automake, I don't see what we can do (except reporting a bug against automake).
> 

It's not his own script, but one that is documented in a macports wiki:

https://trac.macports.org/wiki/UsingTheRightCompiler

The larger issue is the fact that the sdk was not found, because of this script.
For instance, in .../trunk/csl/fox/configure.ac I found these lines:

 if gcc -isysroot /Developer/SDKs/MacOSX10.7.sdk -arch ix86_64 conftest.c -o conftest > /dev/null 2>&1
 then
   AC_MSG_NOTICE([x96_64 binary creation will probably be possible using 10.7])
   else
     AC_MSG_ERROR([Need MACOSX SDK version 10.6 or 10.7])
   fi
 fi

any explicit "gcc" calls get rerouted by that script and return error. There may 
be others in your code, but I haven't looked at them all.

>> I'm now faced with a choice: either I patch the config/make scripts to make 
>> use of the environment variables (like $CC) that MacPorts passes (and I have 
>> no idea how much effort it would take), or abandon the work I started. I 
>> don't know if this is something you planned on doing already.
> 
> I don't have any problem with modifying the scripts to make them work - though I 
> think that this needs more analysis to understand the problem. Ie., is it indeed 
> config.guess that returns the wrong architecture? If so, then why does it happen 
> only for Reduce, and not for other programs that make use of GNU automake? Is 
> this a general problem, or specific to the aforementioned individual's special 
> environment?
> 
> If config.guess is right in determining the architecture, at what point is it 
> replaced by the wrong one, and why?
> 
> Did I understand correctly that you cannot test on 10.6 yourself, only on 10.7?

Right, I do not have 10.6 available to test. But I know for a fact that Xport (which
downloads the psl binaries) built on 10.6 without that script and failed with the 
script present.

Is their a quick way to search for explicit "gcc" calls in all your config/make files?

> 
>  Rainer
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers


-Mark

Re: [Reduce-algebra-developers] emacs support files

[Francis W. <f.j...@li...>]

I have just checked in reduce-run.el, reduce-ide.texinfo and a README file,
so all the source files are now in the SourceForge subversion repository. I
don't think it would be appropriate to include derived files such as
reduce-ide.pdf, although I'm open to persuasion. Instead, I'm thinking of
making the documentation available as HTML and PDF via the REDUCE web site.
The link there needs updating anyway since it points to centaur.

Best wishes, Francis

> -----Original Message-----
> From: Andreas Eder [mailto:and...@gm...]
> Sent: 30 December 2011 4:53 pm
> To: Rainer Schöpf
> Cc: red...@li...
> Subject: [Reduce-algebra-developers] emacs support files
> 
> Hi,
> 
> in trunk/generic/emacs/ there is the elisp reduce mode file
reduce-mode.el. But
> (even though it is mentioned in the code) the run support for interactive
session
> is missing: reduce-run.el Also all the docs (reduce-ide.pdf etc.) are
missing.
> Everything can be found on
> http://centaur.maths.qmw.ac.uk/emacs/reduce_ide/ but I think it should be
in
> the source repository.
> 
> Greetings and thanks for the good work,
> 
> Andreas Eder
> --
> ceterum censeo redmondinem esse delendam.
> 
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
virtual
> desktops. With this all-in-one solution, easily deploy virtual desktops
for less than
> the cost of PCs and save 60% on VDI infrastructure costs. Try it free!
> http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[Rainer S. <rai...@gm...>]

Hello Mark,

 > "uname -p" returns the architecture of the kernel. On an Intel Mac that could 
 > be i386 or x86_64, depending on what kernel your Mac uses. There are 32-bit 
 > Macs (like the original MacBookPro1,1) that use the 32-bit kernel, there are 
 > 64-bit Macs (MacBookPro3,1) that use the 32-bit kernel, and there are more 
 > modern 64-bit Macs that use the 64-bit kernel. The bitness of the kernel is 
 > not an indication of the architecture of programs the computer can run.
 > 
 > I've been discussing this with the folks at MacPorts as well. They like 
 > programs to make no attempt at all to determine what architecture of programs 
 > they can run, and would prefer programs to rely on the CFLAGS, CXXFLAGS, 
 > LDFLAGS etc. variables in which we instruct the compiler for what 
 > architecture to build. (I'm not making any requests here, only giving you 
 > background info).
 >
 > The macports individual who tested my install script on snow leopard, had his 
 > own script to detect whether a config/make file is using ${configure.cc} 
 > instead of running "gcc" explicitly. When your config tried to determine 
 > whether the C preprocessor defines the symbol __LP64__ the aforementioned 
 > script was found instead, producing the error.

Allow me to point out again that the config.guess script that tries to determine 
whether the C preprocessor defines the symbol __LP64__ (and from which I quoted 
some lines in an earlier mail message) is not part of the Reduce subversion 
repository.  It is actually generated automatically by GNU automake as part of 
the build process.

I don't have a Mac, so I can only do an educated guess on what is causing the 
problem.  If config.guess is indeed the cause, then this is not specific to 
Reduce, but may appear for any other program that relies on automake/autoconf.

On the other hand, it may well be that config.guess is doing what it should, but 
that there is an interaction with another part of the Reduce build process. 

So, this person's using his own script is a standard method, or rather not?  
Because if it isn't "standard" in the sense that it plays well together with GNU 
automake, I don't see what we can do (except reporting a bug against automake).

 > I'm now faced with a choice: either I patch the config/make scripts to make 
 > use of the environment variables (like $CC) that MacPorts passes (and I have 
 > no idea how much effort it would take), or abandon the work I started. I 
 > don't know if this is something you planned on doing already.

I don't have any problem with modifying the scripts to make them work - though I 
think that this needs more analysis to understand the problem. Ie., is it indeed 
config.guess that returns the wrong architecture? If so, then why does it happen 
only for Reduce, and not for other programs that make use of GNU automake? Is 
this a general problem, or specific to the aforementioned individual's special 
environment?

If config.guess is right in determining the architecture, at what point is it 
replaced by the wrong one, and why?

Did I understand correctly that you cannot test on 10.6 yourself, only on 10.7?

  Rainer

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

On Jan 6, 2012, at 12:21 AM, Rainer Schöpf wrote:

> On Wed, 4 Jan 2012 at 19:24 -0600, mark brethen wrote:
> 
>> I developed a macports installation script on mac os x 10.7 (lion) and it works fine. I received some reports that it does not build on 10.6 (snow leopard). I have log files for both my lion install and a snow leopard install, but they're pretty big (let me know where to post them). It appears to be forcing a universal build (ppc i386) but 10.6 is 64, and it complains about not finding the SDK for 10.6.  I've had no issues building csl (64) on 10.7.
>> 
>> Info on snow leopard install:
>> 
>> $ uname -a
>> Darwin lavergne.gotdns.org 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
>> 
>> $ ls /Developer/SDKs/
>> MacOSX10.6.sdk
>> 
>> Info on lion install:
>> 
>> Marks-MacBook-Pro:~ marbre$ uname -a
>> Darwin Marks-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
>> 
>> Marks-MacBook-Pro:~ marbre$ ls /Developer/SDKs/
>> MacOSX10.6.sdk MacOSX10.7.sdk
> 
> Mark, there is little point in posting to the sf help forum instead of this 
> mailing list.
> 
> The relevant part of config.guess is this:
> 
>    *:Darwin:*:*)
>        UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
>        case $UNAME_PROCESSOR in
>            i386)
>                eval $set_cc_for_build
>                if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
>                  if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
>                      (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
>                      grep IS_64BIT_ARCH >/dev/null
>                  then
>                      UNAME_PROCESSOR="x86_64"
>                  fi
>                fi ;;
>            unknown) UNAME_PROCESSOR=powerpc ;;
>        esac
>        echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
>        exit ;;
> 
> As you can see, since uname -p returns i386 on 64 bit Darwin, it tries to 
> determine whether the C preprocessor defines the symbol __LP64__ .
> 
> config.guess is part of GNU autoconf, so it is not something beyond our scope. 
> Maybe you have different versions of autoconf?
> 
> Rainer
> 
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual 
> desktops for less than the cost of PCs and save 60% on VDI infrastructure 
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers


"uname -p" returns the architecture of the kernel. On an Intel Mac that could be i386 or x86_64, depending on what kernel your Mac uses. There are 32-bit Macs (like the original MacBookPro1,1) that use the 32-bit kernel, there are 64-bit Macs (MacBookPro3,1) that use the 32-bit kernel, and there are more modern 64-bit Macs that use the 64-bit kernel. The bitness of the kernel is not an indication of the architecture of programs the computer can run.

I've been discussing this with the folks at MacPorts as well. They like programs to make no attempt at all to determine what architecture of programs they can run, and would prefer programs to rely on the CFLAGS, CXXFLAGS, LDFLAGS etc. variables in which we instruct the compiler for what architecture to build. (I'm not making any requests here, only giving you background info).

The macports individual who tested my install script on snow leopard, had his own script to detect whether a config/make file is using ${configure.cc} instead of  running "gcc" explicitly. When your config tried to determine whether the C preprocessor defines the symbol __LP64__  the aforementioned script was found instead, producing the error. 

I'm now faced with a choice: either I patch the config/make scripts to make use of the environment variables (like $CC) that MacPorts passes (and I have no idea how much effort it would take), or abandon the work I started. I don't know if this is something you planned on doing already.

-Mark

Re: [Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[Rainer S. <rai...@gm...>]

On Wed, 4 Jan 2012 at 19:24 -0600, mark brethen wrote:

 > I developed a macports installation script on mac os x 10.7 (lion) and it works fine. I received some reports that it does not build on 10.6 (snow leopard). I have log files for both my lion install and a snow leopard install, but they're pretty big (let me know where to post them). It appears to be forcing a universal build (ppc i386) but 10.6 is 64, and it complains about not finding the SDK for 10.6.  I've had no issues building csl (64) on 10.7.
 > 
 > Info on snow leopard install:
 > 
 > $ uname -a
 > Darwin lavergne.gotdns.org 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64
 > 
 > $ ls /Developer/SDKs/
 > MacOSX10.6.sdk
 > 
 > Info on lion install:
 > 
 > Marks-MacBook-Pro:~ marbre$ uname -a
 > Darwin Marks-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
 > 
 > Marks-MacBook-Pro:~ marbre$ ls /Developer/SDKs/
 > MacOSX10.6.sdk MacOSX10.7.sdk

Mark, there is little point in posting to the sf help forum instead of this 
mailing list.

The relevant part of config.guess is this:

    *:Darwin:*:*)
        UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown
        case $UNAME_PROCESSOR in
            i386)
                eval $set_cc_for_build
                if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then
                  if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
                      (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \
                      grep IS_64BIT_ARCH >/dev/null
                  then
                      UNAME_PROCESSOR="x86_64"
                  fi
                fi ;;
            unknown) UNAME_PROCESSOR=powerpc ;;
        esac
        echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE}
        exit ;;

As you can see, since uname -p returns i386 on 64 bit Darwin, it tries to 
determine whether the C preprocessor defines the symbol __LP64__ .

config.guess is part of GNU autoconf, so it is not something beyond our scope. 
Maybe you have different versions of autoconf?

 Rainer

Re: [Reduce-algebra-developers] emacs support files

[Francis W. <f.j...@qm...>]

OK. I'll see what I can do about that. I need to start moving things off
centaur anyway.

Francis

> -----Original Message-----
> From: Andreas Eder [mailto:and...@gm...]
> Sent: 30 December 2011 4:53 pm
> To: Rainer Schöpf
> Cc: red...@li...
> Subject: [Reduce-algebra-developers] emacs support files
> 
> Hi,
> 
> in trunk/generic/emacs/ there is the elisp reduce mode file
reduce-mode.el. But
> (even though it is mentioned in the code) the run support for interactive
session
> is missing: reduce-run.el Also all the docs (reduce-ide.pdf etc.) are
missing.
> Everything can be found on
> http://centaur.maths.qmw.ac.uk/emacs/reduce_ide/ but I think it should be
in
> the source repository.
> 
> Greetings and thanks for the good work,
> 
> Andreas Eder
> --
> ceterum censeo redmondinem esse delendam.
> 
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
virtual
> desktops. With this all-in-one solution, easily deploy virtual desktops
for less than
> the cost of PCs and save 60% on VDI infrastructure costs. Try it free!
> http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

[Reduce-algebra-developers] build problems on mac os x 10.6 (snow leopard)

[mark b. <mbr...@ai...>]

I developed a macports installation script on mac os x 10.7 (lion) and it works fine. I received some reports that it does not build on 10.6 (snow leopard). I have log files for both my lion install and a snow leopard install, but they're pretty big (let me know where to post them). It appears to be forcing a universal build (ppc i386) but 10.6 is 64, and it complains about not finding the SDK for 10.6.  I've had no issues building csl (64) on 10.7.

Info on snow leopard install:

$ uname -a
Darwin lavergne.gotdns.org 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64

$ ls /Developer/SDKs/
MacOSX10.6.sdk

Info on lion install:

Marks-MacBook-Pro:~ marbre$ uname -a
Darwin Marks-MacBook-Pro.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

Marks-MacBook-Pro:~ marbre$ ls /Developer/SDKs/
MacOSX10.6.sdk MacOSX10.7.sdk



-Mark

Re: [Reduce-algebra-developers] saveimage.sh error line 81

[Mark B. <mar...@gm...>]

On Dec 28, 2011, at 6:21 AM, Rainer Schöpf wrote:

> debianbuild/debian/rules gives can be a guideline on how to do this. (I also 
> noticed that you copied only the html files from the doc/manual directory, 
> missing png and css files).

Rainer,

I did not find any png files after making the html files; only html and css. The html source shows <a href="http://sourceforge.net/"><img src="http://c.fsdn.com/sf/images/sfx_logo2.png"></a> it is not a local image.

Happy New Year!

Mark