On Nov 23, 2007, at 4:38 PM, Thomas Treichl wrote:
Ben Abbott schrieb:
On Nov 23, 2007, at 2:05 PM, Thomas Treichl wrote:
Ben Abbott schrieb:
On Nov 23, 2007, at 12:53 PM, Thomas Treichl wrote:
Ben Abbott schrieb:
On Nov 22, 2007, at 3:35 PM, Thomas Treichl wrote:
Ben Abbott schrieb:
Thomas,
There's a thread on sourceforge here
http://sourceforge.net/tracker/index.php?func=detail&aid=1825780&group_id=17203&atid=414256
<http://sourceforge.net/tracker/index.php?func=detail&aid=1825780&group_id=17203&atid=414256
<http://sourceforge.net/tracker/index.php?func=detail&aid=1825780&group_id=17203&atid=414256>>
I've never encountered a seg-fault using a ppc. Further, I only
encounter a seg-fault when I install SuiteSparse *without*
libcsparse.a, build Octave-2.9.17, and try to install
Octave-Forge-20071014. When I include libcsparse.a in the
SuiteSparse install, or remove SuiteSparse entirely, I have no
problem ... I've duplicated that effort twice.
Sounds to me being an optimization problem or something like
that when building SuiteSparse?! I'm compiling SuiteSparse 3.0.0
since I compile Octave 2.9.12 and use libcsparse.a before I
compile Octave. I also apply the patch SuiteSparse-3.0.0.diff
before building SuiteSparse without metis (don't know if you
have a current SVN of Octave-forge checked out, here is the link)
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/MacOSX/solvedeps
Modify Line 77 (+F77 = f2c) of that *.diff file into your needs
for gfortran and then build another SuiteSparse,
bash~:$ export CC=gcc
bash~:$ export CFLAGS="-fno-common -no-cpp-precomp
-fexceptions -D_POSIX_C_SOURCE -D__NOEXTENSIONS__ -DNPARTITION"
bash~:$ make
try to use that created libcsparse.a instead... I don't know
which option actually fails for you but you can add one flag by
another in F77FLAGS of ./SuiteSparse/UFconfig/UFconfig.mk or in
CFLAGS above (eg. -O3 -mieee-fp ...) - doesn't Fink already have
a SuiteSparse package ready?
Thomas,
The sourceforge link you brought to my attention looks like it
will be useful in resolving the problem with Octave and
Octave-Forge using Fink.
Unfortunately, I've not been able to get the diff's to apply
using 'patch'. Can you tell me what specific syntax is needed?
... hmmm, perhaps I should tell you what I did, and you can tell
me what I did wrong ;-)
After placing the SuiteSparse folder and SuiteSparse-3.0.0.diff
in the same location, I tried ...
patch <./SuiteSparse-3.0.0.diff
Hi Ben,
sorry for being late, yes you need to
patch -p0 < SuiteSparse-3.0.0.diff
That should work.
Thomas
Thanks.
Another question. Are you using Xcode to build Octave and its
dependencies?
If so, and you have any desire to move on to gfortran (from f2c),
MacResearch has instructions on doing so.
http://macresearch.org/xcode_gfortran_contest_winner_damien_bobillot
I haven't tried it out yet. Mainly because I have no experience
with Xcode and doubt I'd be successful in creating an Xcode project
for Octave. However, I am interested in such, since (I suspect) it
would be useful in isolating the cause of the segmentation fault
problem.
Ben
Yes, I'm using XCode's compilers and nothing else. I need to make
sure that Mac users that run the Octave.app have the same compilers
then I have - original compilers are the only solution. We have gone
through this whole discussion about gfortran for the Octave.app
(search Octave mailing lists of this year about the variuos threads
we had before Octave.app appeared) and to make sure that Octave.app
users have the same system we say 'use Apple's latest XCode tools'
to make sure that packages are installed correctly...
Note: What you shouldn't do at all: Don't mix f2c with gfortran for
the dependencies of Octave. Decide either to use one and the same
Fortran compiler for building all dependencies and Octave or decide
to use f2c for all dependencies and Octave. Don't mix Fortran
compilers, problems like you explained may occur then and nobody
knows why/where/when they appear.
Eg. if you use Apple's vecLib library and use the switch '-framework
vecLib' >from the Octave configure script then you must use f2c
because Apple's blas library was compiled using f2c, so if you use
gfortran then you must bring your own blas library that is also
compiled with gfortran. This may be one problem that xan occur with
SuiteSparse if you use gfortran but you also use Apple's blas
library that was compiled with f2c...
A long story isn't it, it took us weeks of spare time to find out
things like that before building Octave.app... Hope that helps for
you...
Thomas
Thanks again.
I'm not thrilled to hear that gfortran has problem with vecLib. Is it
possible that such problems are related to optimization? I've been
using vecLib with both g77, g95, and gfortran for many of my projects
at work. Thus far, no problems. I find that gfortran/g95 are
significantly faster than g77/f2c.
Before using f2c on MacOSX I also made my experiences with
gfortrans(s) (that's about half a year ago now). I found about 5..7
binary builds at the Internet and can remember that only 2 of them did
a good job. I also remember that the gfortran package of R.app and the
gfortran from there
http://gcc.gnu.org/wiki/GFortranBinaries
did a good job with XCode's gcc 4.0.1, all the others out there
didn't. So I expect that building a working GFortran (without the
other GNU compilers) that can do its job together with the gcc 4.0.1
that comes with XCode is not an easy job...
But that's all my small user's point of view ;)
Reading your last post, reminded me that I use a different version of
gcc when using gfortran.
gfortran --version
GNU Fortran (GCC) 4.2.2
Copyright (C) 2007 Free Software Foundation, Inc.
Perhaps when Apple gets around to 4.2.x we'll also find gfortran included.