matlisp-users

Re: [Matlisp-users] Matlisp on OS X

[<si...@EE...>]

This looks like a makefile problem.  Although once that is
fixed I'm sure others will follow.

These two lines in matlisp.mk tell 'make' that dgemm.o should
be build from dgemm.f or dgemm.c (whichever one it finds)
Perhaps the make on OS X doesn't understand this.

But before that.  Did you download the released tar'd file or 
did you get the files from the CVS repository.  You should
get the latter since the released file is way too old and won't
work with your version of Allegro.

  --Tunc

----- Original Message -----
From: ju...@mi...
Date: Saturday, April 19, 2003 3:06 pm
Subject: [Matlisp-users] Matlisp on OS X

> Hi all
> 
> I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.
> 
> I installed g77 via fink and set F77 to /sw/bin/g77
> 
> Ihave installed ATLAS using fink and run:
> 
> ./configure FreeBSD
> 
> (as was suggested at
> http://mail.gnu.org/archive/html/gcl-devel/2002-07/msg00029.html), 
> whichyields output 1 (see below). All seems OK at this point to my 
> untrainedeye.
> 
> I then do
> 
> make allegro
> 
> which fails pretty quickly with output 2 (see below)
> 
> Has anyone got Matlisp going on OS X? OS X is just UNIX; give that 
> Matlispexists for Linux, it should also be OK with OS X???
> 
> Your help would be very much appreciated!!!!
> 
> Chris
> 
> Output 1 (listing of the configure step):
> 
> ./configure FreeBSD
> configure: warning: FreeBSD: invalid host type
> loading cache ./config.cache
> checking whether the Fortran 77 compiler (/sw/bin/g77  ) works... yes
> checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
> cross-compiler... no
> checking whether we are using GNU Fortran 77... (cached) yes
> checking whether /sw/bin/g77 accepts -g... (cached) yes
> checking for ranlib... (cached) ranlib
> checking host system type... Invalid configuration `FreeBSD': machine
> `FreeBSD' not recognized
> 
> checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -
> lcrt1.o-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
> -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
> checking for gcc... (cached) gcc
> checking whether the C compiler (gcc  ) works... yes
> checking whether the C compiler (gcc  ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> configure: warning: Oops! Matlisp is tested on Solaris, SunOS or Linux
> configure: warning: Matlisp may not compile on your system .
> creating ./config.status
> creating matlisp.mk
> creating lib/lazy-loader.lisp
> 
> Output 2 (listing of the make step):
> 
> make allegro
> make -f matlisp.mk shared
> make[1]: *** No rule to make target 
> `/usr/local/LAPACK/BLAS/SRC/dgemm.o',needed by `shared'.  Stop.
> make: *** [lib/libmatlispshared.so] Error 2
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Matlisp on OS X

[<si...@EE...>]

These two lines:

.f.o:
	$(F77) $(FFLAGS) -o $@ -c $<

.c.o:
	$(CC) $(CFLAGS) -o $@ -c $<


----- Original Message -----
From: si...@ee...
Date: Sunday, April 20, 2003 11:50 pm
Subject: Re: [Matlisp-users] Matlisp on OS X

> This looks like a makefile problem.  Although once that is
> fixed I'm sure others will follow.
> 
> These two lines in matlisp.mk tell 'make' that dgemm.o should
> be build from dgemm.f or dgemm.c (whichever one it finds)
> Perhaps the make on OS X doesn't understand this.
> 
> But before that.  Did you download the released tar'd file or 
> did you get the files from the CVS repository.  You should
> get the latter since the released file is way too old and won't
> work with your version of Allegro.
> 
>  --Tunc
> 
> ----- Original Message -----
> From: ju...@mi...
> Date: Saturday, April 19, 2003 3:06 pm
> Subject: [Matlisp-users] Matlisp on OS X
> 
> > Hi all
> > 
> > I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.
> > 
> > I installed g77 via fink and set F77 to /sw/bin/g77
> > 
> > Ihave installed ATLAS using fink and run:
> > 
> > ./configure FreeBSD
> > 
> > (as was suggested at
> > http://mail.gnu.org/archive/html/gcl-devel/2002-
> 07/msg00029.html), 
> > whichyields output 1 (see below). All seems OK at this point to 
> my 
> > untrainedeye.
> > 
> > I then do
> > 
> > make allegro
> > 
> > which fails pretty quickly with output 2 (see below)
> > 
> > Has anyone got Matlisp going on OS X? OS X is just UNIX; give 
> that 
> > Matlispexists for Linux, it should also be OK with OS X???
> > 
> > Your help would be very much appreciated!!!!
> > 
> > Chris
> > 
> > Output 1 (listing of the configure step):
> > 
> > ./configure FreeBSD
> > configure: warning: FreeBSD: invalid host type
> > loading cache ./config.cache
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) 
> works... yes
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
> > cross-compiler... no
> > checking whether we are using GNU Fortran 77... (cached) yes
> > checking whether /sw/bin/g77 accepts -g... (cached) yes
> > checking for ranlib... (cached) ranlib
> > checking host system type... Invalid configuration `FreeBSD': 
> machine> `FreeBSD' not recognized
> > 
> > checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -
> > lcrt1.o-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
> > -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc  ) works... yes
> > checking whether the C compiler (gcc  ) is a cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> > configure: warning: Oops! Matlisp is tested on Solaris, SunOS or 
> Linux> configure: warning: Matlisp may not compile on your system .
> > creating ./config.status
> > creating matlisp.mk
> > creating lib/lazy-loader.lisp
> > 
> > Output 2 (listing of the make step):
> > 
> > make allegro
> > make -f matlisp.mk shared
> > make[1]: *** No rule to make target 
> > `/usr/local/LAPACK/BLAS/SRC/dgemm.o',needed by `shared'.  Stop.
> > make: *** [lib/libmatlispshared.so] Error 2
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Matlisp-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matlisp-users
> > 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Matlisp on OS X

[<ju...@mi...>]

Hi again

Thanks for the help. I'm relatively new to UNIX and OS X, so I'd be
grateful for you help *and* patience... :-)

On the makefile front, I am using GNU Make version 3.79 -- I'm not aware
that there are any major differences between this and its Linux/Solaris
counterparts.

If I manage to get Matlisp going on OS X I plan to put together a howto
document. I have made some progress, and I think I've narrowed the problem
down substantially.

1. I was using one of the Matlisp releases. I've now checked the latest
version of Matlisp out of CVS.

2. One of the problems I found was regarding the config.sub and
config.guess files. Apple provides version of these files so porting is
easier (see:
developer.apple.com/techpubs/macosx/Darwin/GettingStarted/PortingUNIX/compiling/chapter_3_section_8.html).
So I did:

mv config.guess config.guess.dist
mv config.sub config.sub.dist
ln -s /usr/share/automake-1.6/config.guess .
ln -s /usr/share/automake-1.6/config.sub .

3. Trying to do the aclocal, autoconf, automake sequence, I got complains
about missing AM_INIT_AUTOMAKE, ./aclocal.m4, ./mkinstalldirs and
./missing. I copied aclocal.m4, mkinstalldirs and missing from a C++
project I had. I guess this is a dodgy step -- I think aclocal.m4 needs to
be generated by doing aclocal (but when I tried that, no aclocal.m4 is
created). Copying in the files missing and mkinstalldirs seemed to placate
autoconf on errors regarding those files, but it complains that "your
implementation of AM_INIT_AUTOMAKE comes from an automake: old Automake
version.  You should recreate aclocal.m4 automake: with aclocal and run
automake again."

4. Doing ./configure --with-lisp=acl --with-lisp-exec=alisp
--prefix=/Users/chris/Desktop/Matlisp/matlisp/ yields the following
problem:

[snip]
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

5. Looking is config.log:

[snip]
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
(prerel
ease)
configure:1819: $? = 0
configure:1821: gcc -V </dev/null >&5
gcc: argument to `-V' is missing
configure:1824: $? = 1
configure:1848: checking for C compiler default output
configure:1851: gcc -c -O2   conftest.c  >&5
configure:1854: $? = 0
configure:1900: result: b.out
configure:1905: checking whether the C compiler works
configure:1911: ./b.out
./configure: ./b.out: No such file or directory
configure:1914: $? = 127
configure:1923: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

6. A web search suggested the following potential causes:
a) Using a different compiler than the one used to build Matlisp on the
developer's workstations.
b) LD_LIBRARY_PATH set to something that doesn't work with the default
compiler.
c) If configure was created with the wrong version of autoconf.

I'm using the gcc toolchain, so I guess I'm OK on point a). I don't have
LD_LIBRARY_PATH set in my environment -- perhaps it's set in Matlisp's
build system? I'm not sure about point c) -- Apple install Automake 1.6,
but I've had to upgrate to 1.7 for another project, so there's a potential
conflict between the config.guess and config.sub files brought into the
Matlisp dir from Automake 1.7 and me using the tools from Automake 1.7.

As I said, I'm very appreciative of your help on this matter.

Chris


On Sun, 20 Apr 2003, si...@EE... wrote:

> This looks like a makefile problem.  Although once that is
> fixed I'm sure others will follow.
>
> These two lines in matlisp.mk tell 'make' that dgemm.o should
> be build from dgemm.f or dgemm.c (whichever one it finds)
> Perhaps the make on OS X doesn't understand this.
>
> But before that.  Did you download the released tar'd file or
> did you get the files from the CVS repository.  You should
> get the latter since the released file is way too old and won't
> work with your version of Allegro.
>
>   --Tunc
>
> ----- Original Message -----
> From: ju...@mi...
> Date: Saturday, April 19, 2003 3:06 pm
> Subject: [Matlisp-users] Matlisp on OS X
>
> > Hi all
> >
> > I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.
> >
> > I installed g77 via fink and set F77 to /sw/bin/g77
> >
> > Ihave installed ATLAS using fink and run:
> >
> > ./configure FreeBSD
> >
> > (as was suggested at
> > http://mail.gnu.org/archive/html/gcl-devel/2002-07/msg00029.html),
> > whichyields output 1 (see below). All seems OK at this point to my
> > untrainedeye.
> >
> > I then do
> >
> > make allegro
> >
> > which fails pretty quickly with output 2 (see below)
> >
> > Has anyone got Matlisp going on OS X? OS X is just UNIX; give that
> > Matlispexists for Linux, it should also be OK with OS X???
> >
> > Your help would be very much appreciated!!!!
> >
> > Chris
> >
> > Output 1 (listing of the configure step):
> >
> > ./configure FreeBSD
> > configure: warning: FreeBSD: invalid host type
> > loading cache ./config.cache
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) works... yes
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
> > cross-compiler... no
> > checking whether we are using GNU Fortran 77... (cached) yes
> > checking whether /sw/bin/g77 accepts -g... (cached) yes
> > checking for ranlib... (cached) ranlib
> > checking host system type... Invalid configuration `FreeBSD': machine
> > `FreeBSD' not recognized
> >
> > checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -
> > lcrt1.o-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
> > -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc  ) works... yes
> > checking whether the C compiler (gcc  ) is a cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> > configure: warning: Oops! Matlisp is tested on Solaris, SunOS or Linux
> > configure: warning: Matlisp may not compile on your system .
> > creating ./config.status
> > creating matlisp.mk
> > creating lib/lazy-loader.lisp
> >
> > Output 2 (listing of the make step):
> >
> > make allegro
> > make -f matlisp.mk shared
> > make[1]: *** No rule to make target
> > `/usr/local/LAPACK/BLAS/SRC/dgemm.o',needed by `shared'.  Stop.
> > make: *** [lib/libmatlispshared.so] Error 2
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Matlisp-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matlisp-users
> >
>
>

Re: [Matlisp-users] Matlisp on OS X

[Raymond T. <to...@rt...>]

>>>>> "Chris" == junk2  <ju...@mi...> writes:

    Chris> 1. I was using one of the Matlisp releases. I've now checked the latest
    Chris> version of Matlisp out of CVS.

Good.

    Chris> 2. One of the problems I found was regarding the config.sub and
    Chris> config.guess files. Apple provides version of these files so porting is
    Chris> easier (see:
    Chris> developer.apple.com/techpubs/macosx/Darwin/GettingStarted/PortingUNIX/compiling/chapter_3_section_8.html).
    Chris> So I did:

I'll take a look at this and see if we can use these instead for the
other supported platforms.

    Chris> 3. Trying to do the aclocal, autoconf, automake sequence, I got complains
    Chris> about missing AM_INIT_AUTOMAKE, ./aclocal.m4, ./mkinstalldirs and
    Chris> ./missing. I copied aclocal.m4, mkinstalldirs and missing from a C++

We don't use aclocal or automake.  Running autoconf should be enough.
I don't know what will happen if you run aclocal and automake.

    Chris> [snip]
    Chris> Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
    Chris> (prerel
    Chris> ease)
    Chris> configure:1819: $? = 0
    Chris> configure:1821: gcc -V </dev/null >&5
    Chris> gcc: argument to `-V' is missing
    Chris> configure:1824: $? = 1
    Chris> configure:1848: checking for C compiler default output
    Chris> configure:1851: gcc -c -O2   conftest.c  >&5
    Chris> configure:1854: $? = 0
    Chris> configure:1900: result: b.out
    Chris> configure:1905: checking whether the C compiler works
    Chris> configure:1911: ./b.out
    Chris> ./configure: ./b.out: No such file or directory

Can you figure this out?  Does the compiler really put the executable
in b.out instead of a.out?

Ray

Re: [Matlisp-users] Matlisp on OS X

[<ju...@mi...>]

Hi again

OK, given you're not using aclocal or automake, I've checked a fresh copy
out of CVS. I have make links to Apple's versions of the config.guess and
config.sub files. I ran autoconf. I then ran the

./configure --with-lisp=acl --with-lisp-exec=alisp
--prefix=/Users/chris/Desktop/Matlisp/matlisp/

Command, which gave me pretty much the same output as before:

alisp --prefix=/Users/chris/Desktop/Matlisp/matlisp/
checking build system type... powerpc-apple-darwin6.5
checking host system type... powerpc-apple-darwin6.5
checking target system type... powerpc-apple-darwin6.5
checking for ranlib... ranlib
checking for gcc... gcc
checking for C compiler default output... b.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

So, again, b.out appears, although I can't actually see that file on my
system (nor the conftest.c file) -- perhaps these get cleaned up in the
./configure... script?

One thing I have just remembered: When writing C++ code for OS X, one has
to explicitly link against libstdc++.a, which, as far as I understand, is
not the case on Linux, say. Could a similar problem be to blame here?

I have included config.log below, in case that casts more light on the
problem.

Thanks again.

Chris

-- Contents of config.log --

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.57.  Invocation command line was

  $ ./configure --with-lisp=acl --with-lisp-exec=alisp
--prefix=/Users/chris/Desktop/Matlisp/matlisp/

## --------- ##
## Platform. ##
## --------- ##

hostname = Totty.local.
uname -m = Power Macintosh
uname -r = 6.5
uname -s = Darwin
uname -v = Darwin Kernel Version 6.5: Mon Apr  7 17:05:38 PDT 2003;
root:xnu/xnu-344.32.obj~1/RELEASE_PPC

/usr/bin/uname -p = powerpc
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = Mach kernel version:
	 Darwin Kernel Version 6.5:
Mon Apr  7 17:05:38 PDT 2003; root:xnu/xnu-344.32.obj~1/RELEASE_PPC


Kernel configured for up to 2 processors.
1 processor is physically available.
Processor type: ppc750 (PowerPC 750)
Processor active: 0
Primary memory available: 256.00 megabytes.
Default processor set: 53 tasks, 148 threads, 1 processors
Load average: 2.33, Mach factor: 0.30
unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1269: checking build system type
configure:1287: result: powerpc-apple-darwin6.5
configure:1295: checking host system type
configure:1309: result: powerpc-apple-darwin6.5
configure:1317: checking target system type
configure:1331: result: powerpc-apple-darwin6.5
configure:1452: checking for ranlib
configure:1468: found /usr/bin/ranlib
configure:1479: result: ranlib
configure:1538: checking for gcc
configure:1564: result: gcc
configure:1808: checking for C compiler version
configure:1811: gcc --version </dev/null >&5
gcc (GCC) 3.1 20020420 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

configure:1814: $? = 0
configure:1816: gcc -v </dev/null >&5
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
(prerelease)
configure:1819: $? = 0
configure:1821: gcc -V </dev/null >&5
gcc: argument to `-V' is missing
configure:1824: $? = 1
configure:1848: checking for C compiler default output
configure:1851: gcc -c -O2   conftest.c  >&5
configure:1854: $? = 0
configure:1900: result: b.out
configure:1905: checking whether the C compiler works
configure:1911: ./b.out
./configure: ./b.out: No such file or directory
configure:1914: $? = 127
configure:1923: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=powerpc-apple-darwin6.5
ac_cv_build_alias=powerpc-apple-darwin6.5
ac_cv_env_CC_set=set
ac_cv_env_CC_value=gcc
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-c -O2'
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_F77_set=set
ac_cv_env_F77_value=/sw/bin/g77
ac_cv_env_FFLAGS_set=
ac_cv_env_FFLAGS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_host=powerpc-apple-darwin6.5
ac_cv_host_alias=powerpc-apple-darwin6.5
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_RANLIB=ranlib
ac_cv_target=powerpc-apple-darwin6.5
ac_cv_target_alias=powerpc-apple-darwin6.5

## ----------------- ##
## Output variables. ##
## ----------------- ##

ATLAS_DIR=''
ATLAS_LIBS=''
BLAS_OBJS='dgemm.o dswap.o dtrmv.o lsame.o zdotu.o zhemv.o ztrmv.o dgemv.o
dsymv.o  dtrsm.o  zher2.o   ztrsm.o dasum.o  dger.o   dsyr.o   dtrsv.o
zdscal.o zher2k.o ztrsv.o daxpy.o  dsyr2.o  dzasum.o xerbla.o  zgemm.o
zherk.o dcabs1.o dnrm2.o  dsyr2k.o dznrm2.o  zaxpy.o  zgemv.o  zscal.o
dcopy.o  drot.o   dsyrk.o  idamax.o  zcopy.o  zgerc.o  zswap.o ddot.o
dscal.o  dtrmm.o  izamax.o  zdotc.o  zgeru.o  ztrmm.o dsymm.o'
CC='gcc'
CFLAGS='-c -O2'
CLIBS=''
CPPFLAGS=''
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
F77='/sw/bin/g77'
F77_EXTRA_UNDERSCORE=''
F77_LOWER_CASE=''
F77_UNDERSCORE=''
FFLAGS=''
FLIBS=''
LD=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LISPEVAL='-e'
LISPEXEC='alisp'
LTLIBOBJS=''
NO_ATLAS_LAPACK_OBJS='dgetrf.o zgetrf.o dgetrs.o zgetrs.o dlaswp.o
zlaswp.o dgesv.o zgesv.o'
OBJEXT=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
RANLIB='ranlib'
SHARED_LIB_LDFLAGS=''
SHELL='/bin/sh'
ac_ct_CC='gcc'
ac_ct_F77=''
ac_ct_RANLIB='ranlib'
bindir='${exec_prefix}/bin'
build='powerpc-apple-darwin6.5'
build_alias=''
build_cpu='powerpc'
build_os='darwin6.5'
build_vendor='apple'
datadir='${prefix}/share'
exec_prefix='NONE'
host='powerpc-apple-darwin6.5'
host_alias=''
host_cpu='powerpc'
host_os='darwin6.5'
host_vendor='apple'
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='/Users/chris/Desktop/Matlisp/matlisp/'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
srcdir='.'
sysconfdir='${prefix}/etc'
target='powerpc-apple-darwin6.5'
target_alias=''
target_cpu='powerpc'
target_os='darwin6.5'
target_vendor='apple'

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""

configure: exit 1



On 21 Apr 2003, Raymond Toy wrote:

> >>>>> "Chris" == junk2  <ju...@mi...> writes:
>
>     Chris> 1. I was using one of the Matlisp releases. I've now checked the latest
>     Chris> version of Matlisp out of CVS.
>
> Good.
>
>     Chris> 2. One of the problems I found was regarding the config.sub and
>     Chris> config.guess files. Apple provides version of these files so porting is
>     Chris> easier (see:
>     Chris> developer.apple.com/techpubs/macosx/Darwin/GettingStarted/PortingUNIX/compiling/chapter_3_section_8.html).
>     Chris> So I did:
>
> I'll take a look at this and see if we can use these instead for the
> other supported platforms.
>
>     Chris> 3. Trying to do the aclocal, autoconf, automake sequence, I got complains
>     Chris> about missing AM_INIT_AUTOMAKE, ./aclocal.m4, ./mkinstalldirs and
>     Chris> ./missing. I copied aclocal.m4, mkinstalldirs and missing from a C++
>
> We don't use aclocal or automake.  Running autoconf should be enough.
> I don't know what will happen if you run aclocal and automake.
>
>     Chris> [snip]
>     Chris> Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
>     Chris> (prerel
>     Chris> ease)
>     Chris> configure:1819: $? = 0
>     Chris> configure:1821: gcc -V </dev/null >&5
>     Chris> gcc: argument to `-V' is missing
>     Chris> configure:1824: $? = 1
>     Chris> configure:1848: checking for C compiler default output
>     Chris> configure:1851: gcc -c -O2   conftest.c  >&5
>     Chris> configure:1854: $? = 0
>     Chris> configure:1900: result: b.out
>     Chris> configure:1905: checking whether the C compiler works
>     Chris> configure:1911: ./b.out
>     Chris> ./configure: ./b.out: No such file or directory
>
> Can you figure this out?  Does the compiler really put the executable
> in b.out instead of a.out?
>
> Ray
>

Re: [Matlisp-users] Matlisp on OS X

[Raymond T. <to...@rt...>]

>>>>> "Chris" == junk2  <ju...@mi...> writes:

    Chris> So, again, b.out appears, although I can't actually see that file on my
    Chris> system (nor the conftest.c file) -- perhaps these get cleaned up in the
    Chris> ./configure... script?

Yes, configure will clean it up.  Before we can make progress, we'll
have to solve this problem.  (I do have an iMac running OSX at home,
but don't have acl.)

Try looking through the generated configure script.  Find the place
where conftest.c is created.  And try to compile that up by hand.  

Or you could just do a simple "Hello world!" program, and compile it
using "gcc -c -O2 hello.c" and see where the output goes.  It seems
that b.out is ok.  Then try to run it.

    Chris> One thing I have just remembered: When writing C++ code for OS X, one has
    Chris> to explicitly link against libstdc++.a, which, as far as I understand, is
    Chris> not the case on Linux, say. Could a similar problem be to blame here?

Matlisp doesn't use any C++ code.

Ray

Re: [Matlisp-users] Matlisp on OS X

[Tunc <si...@ee...>]

Hey folks;  the problems we're trying to solve might need some
deeper thought.  I took a moment to look at the Allegro docs
and here is some notes that raise concerns:

http://www.franz.com/support/documentation/6.1/doc/foreign-functions.htm#ff-
on-macosx-1

It says:
----------------------------------------------------------------------------
------------
Appendix I: Building shared libraries on MacOSX
On MacOSX, you must produce a specific type of .dylib file which can be
loaded into Allegro CL. These are called bundle files on MacOSX, and are
fully packaged shared libraries. Unfortunately, they may not be reused as
input to ld() once they have been created, in contrast with shared-objects
on other architectures. However, they may contain undefined symbols, which
may be resolved lazily when the shared-objects are loaded. These may include
symbols in libacl*.dylib such as lisp_value and lisp_call_address, without
having to link against the library. Compile with the -dynamic flag. As an
example:

% cc -dynamic -c foo.c -o foo.o
% ld -bundle /usr/lib/bundle1.o -undefined suppress -o foo.dylib foo.o
Fortran interfacing is not supported at this time.

The general issue of cross linking is discussed in Section 1.7.1 Linking to
Allegro CL shared library on MacOSX.

----------------------------------------------------------------------------
--------

Since I don't have much experience with MacOSX, I don't know whether this is
a show stopper.  Can someone comment??



Thanks, Tunc







----- Original Message -----
From: "Raymond Toy" <to...@rt...>
To: <ju...@mi...>
Cc: "si...@EE..." <si...@ee...>;
<mat...@li...>
Sent: Monday, April 21, 2003 8:31 AM
Subject: Re: [Matlisp-users] Matlisp on OS X


> >>>>> "Chris" == junk2  <ju...@mi...> writes:
>
>     Chris> So, again, b.out appears, although I can't actually see that
file on my
>     Chris> system (nor the conftest.c file) -- perhaps these get cleaned
up in the
>     Chris> ./configure... script?
>
> Yes, configure will clean it up.  Before we can make progress, we'll
> have to solve this problem.  (I do have an iMac running OSX at home,
> but don't have acl.)
>
> Try looking through the generated configure script.  Find the place
> where conftest.c is created.  And try to compile that up by hand.
>
> Or you could just do a simple "Hello world!" program, and compile it
> using "gcc -c -O2 hello.c" and see where the output goes.  It seems
> that b.out is ok.  Then try to run it.
>
>     Chris> One thing I have just remembered: When writing C++ code for OS
X, one has
>     Chris> to explicitly link against libstdc++.a, which, as far as I
understand, is
>     Chris> not the case on Linux, say. Could a similar problem be to blame
here?
>
> Matlisp doesn't use any C++ code.
>
> Ray
>

Re: [Matlisp-users] Matlisp on OS X

[<ju...@mi...>]

Hi again

Thanks to those who have taken the time to offer me some help. In reply to
Raymond's email about checking the C compiler is working, I have been able
to build a C helloworld app fine, and the binary produced using the "gcc
-c -O2 helloworld.c" syntax is called helloworld. So, I don't know where
the name b.out is coming from.

In reply to Tunc's email, I guess there are greater forces at play than my
non-mainstream OS and lack of experience hacking it.

I'd love to get Matlisp going on OS X if possible, and I'm more than
willing to help out in any way I can, but I guess you guys have more
experience getting Matlisp to play nice on UNIX.

As an aside, I'm seeing more and more people 'switch' over to OS X (if
you'll excuse the marketing victim speak), particularly for scientific
work. I know two academic in my dept. who have moved from Linux to OS X,
and several others who have fallen in love with Apple's line of laptops
and are going to 'switch' when they next get a new computer. So, that
being said, I'd encourage support of OS X by the OSS crowd as far as
possible.

Most people use fink (fink.sourceforge.net) to install UNIX apps for OS X,
so perhaps they might be a useful resource to tap into if there is
significant work to be done to port Matlisp to OS X *and* you guys think
this is worth doing.</my .10c>

Thanks again

Chris


On 21 Apr 2003, Raymond Toy wrote:

> >>>>> "Chris" == junk2  <ju...@mi...> writes:
>
>     Chris> So, again, b.out appears, although I can't actually see that file on my
>     Chris> system (nor the conftest.c file) -- perhaps these get cleaned up in the
>     Chris> ./configure... script?
>
> Yes, configure will clean it up.  Before we can make progress, we'll
> have to solve this problem.  (I do have an iMac running OSX at home,
> but don't have acl.)
>
> Try looking through the generated configure script.  Find the place
> where conftest.c is created.  And try to compile that up by hand.
>
> Or you could just do a simple "Hello world!" program, and compile it
> using "gcc -c -O2 hello.c" and see where the output goes.  It seems
> that b.out is ok.  Then try to run it.
>
>     Chris> One thing I have just remembered: When writing C++ code for OS X, one has
>     Chris> to explicitly link against libstdc++.a, which, as far as I understand, is
>     Chris> not the case on Linux, say. Could a similar problem be to blame here?
>
> Matlisp doesn't use any C++ code.
>
> Ray
>

Re: [Matlisp-users] Matlisp on OS X

[Raymond T. <to...@rt...>]

>>>>> "junk2" == junk2  <ju...@mi...> writes:

    Chris> Thanks to those who have taken the time to offer me some help. In reply to
    Chris> Raymond's email about checking the C compiler is working, I have been able
    Chris> to build a C helloworld app fine, and the binary produced using the "gcc
    Chris> -c -O2 helloworld.c" syntax is called helloworld. So, I don't know where
    Chris> the name b.out is coming from.

I'll try to look at this soon on my OSX box at home.

    Chris> Most people use fink (fink.sourceforge.net) to install UNIX apps for OS X,
    Chris> so perhaps they might be a useful resource to tap into if there is
    Chris> significant work to be done to port Matlisp to OS X *and* you guys think
    Chris> this is worth doing.</my .10c>

I think that will depend mostly on you. :-) I don't have ACL on OSX,
so I can't help there.  Perhaps an openmcl port would be useful, but
I'm not really motivated to do that because I don't use my slow OSX
box for any number crunching.

Ray

Re: [Matlisp-users] Matlisp on OS X

[Jeremy S. <sh...@op...>]

As another aside, I was an OS X fan myself, and used it extensively (did a
lot with Haskell FFI under OS X) for my research and private projects.  The
OS itself is beautiful (although the library system is a little
out-of-the-ordinary and I have no tolerance of Objective C).

DISCLAIMER:  My gripes relate to my experience with an Apple Laptop, which
got regular programmer wear-n-tear.  YMMV.

My problem came from the hardware, which you are stuck using if you like OS
X.  I had a laptop that went through two external power thingies, then the
DVD-ROM drive would not close.  It started becoming very frustrating when
the airport card (or antenna) worked "intermittently", and before I knew it,
the computer wouldn't even turn on.  The power button is basically useless,
no response at all from the machine.

The majority of this happened a few months after my initial AppleCare plan
was done and I don't feel like paying a sixth of the price of the laptop
(when new) again.  I don't know that my work won't be stranded on the drive
again, and that I won't be stopped for weeks while it's being fixed -- this
makes it effectively useless to me.

I paid the premium (and there is one, the laptop was slower than a
price-equivalent x86 in comparison, running the same matrix operations) for
OS X, and to ensure that the laptop's provider was AROUND when it came time
to fix it (as it's not peacemeal-fixable like a desktop).  If I had to do it
all over again, I'd revert to anything Turing-complete with a better
warranty and hardware track record.  OS X is beautiful, but the hardware,
not so much.

In short, I think that the adventurous will "switch", but unless your idea
of fun is porting packages and working 10 months out of 12 while it's being
AppleCared for, the eye candy and peace of mind that Apple will be around to
fix these prevalent problems just aren't worth it.  IMHO.

Jeremy



----- Original Message -----
From: <ju...@mi...>
To: "Raymond Toy" <to...@rt...>
Cc: <si...@EE...>; <mat...@li...>
Sent: Monday, April 21, 2003 4:59 PM
Subject: Re: [Matlisp-users] Matlisp on OS X


> Hi again
>
> Thanks to those who have taken the time to offer me some help. In reply to
> Raymond's email about checking the C compiler is working, I have been able
> to build a C helloworld app fine, and the binary produced using the "gcc
> -c -O2 helloworld.c" syntax is called helloworld. So, I don't know where
> the name b.out is coming from.
>
> In reply to Tunc's email, I guess there are greater forces at play than my
> non-mainstream OS and lack of experience hacking it.
>
> I'd love to get Matlisp going on OS X if possible, and I'm more than
> willing to help out in any way I can, but I guess you guys have more
> experience getting Matlisp to play nice on UNIX.
>
> As an aside, I'm seeing more and more people 'switch' over to OS X (if
> you'll excuse the marketing victim speak), particularly for scientific
> work. I know two academic in my dept. who have moved from Linux to OS X,
> and several others who have fallen in love with Apple's line of laptops
> and are going to 'switch' when they next get a new computer. So, that
> being said, I'd encourage support of OS X by the OSS crowd as far as
> possible.
>
> Most people use fink (fink.sourceforge.net) to install UNIX apps for OS X,
> so perhaps they might be a useful resource to tap into if there is
> significant work to be done to port Matlisp to OS X *and* you guys think
> this is worth doing.</my .10c>
>
> Thanks again
>
> Chris
>
>
> On 21 Apr 2003, Raymond Toy wrote:
>
> > >>>>> "Chris" == junk2  <ju...@mi...> writes:
> >
> >     Chris> So, again, b.out appears, although I can't actually see that
file on my
> >     Chris> system (nor the conftest.c file) -- perhaps these get cleaned
up in the
> >     Chris> ./configure... script?
> >
> > Yes, configure will clean it up.  Before we can make progress, we'll
> > have to solve this problem.  (I do have an iMac running OSX at home,
> > but don't have acl.)
> >
> > Try looking through the generated configure script.  Find the place
> > where conftest.c is created.  And try to compile that up by hand.
> >
> > Or you could just do a simple "Hello world!" program, and compile it
> > using "gcc -c -O2 hello.c" and see where the output goes.  It seems
> > that b.out is ok.  Then try to run it.
> >
> >     Chris> One thing I have just remembered: When writing C++ code for
OS X, one has
> >     Chris> to explicitly link against libstdc++.a, which, as far as I
understand, is
> >     Chris> not the case on Linux, say. Could a similar problem be to
blame here?
> >
> > Matlisp doesn't use any C++ code.
> >
> > Ray
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>
>