Fink

thanks Alex!

Never mind, I've made the change to suitesparse.info and committed it.

Let's not commit this just yet (case-sensitivity issue):

Failed: directory /sw/src/fink.build/suitesparse-3.0.0-1/suitesparse
doesn't exist, check the package description

The source unpacks in SuiteSparse/ so specifying SourceDirectory:
SuiteSparse should do it.

sorry about the duplicate posts ... I tried reloading the tracker window
in my browser and it resubmitted the same post a second time.

I did see you post to bugs-octave. I've also posted one with a different
context.

I've never got 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.

Is it possible that Octave requires libcsparse.a to be present when linked
to SuiteSparse?

your last 2 comments, dated 2 days apart, seem identical..
(but a seg-fault is a bug; has to go as a bug-report).

Did you see :
http://www.cae.wisc.edu/pipermail/bug-octave/2007-November/003933.html
?
I did put you in cc...

(In particular, it is not clear from your previous comments whether you
ever
got this seg-fault on ppc ..)

It gives pointers that narrow down the problem quite a bit already

Good luck !

JF

PS: since the presence or not of suitesparse does not affect this
problem,
no reason to hold it up _ so I will commit it as soon as I get a reply
from
octave's maintainer ...

I've been trying to isolate the segmentation fault so that I could post
more context to the Octave forums.

I've done what I can to isolate the errors. When I try to use pkg to
install the toolboxes from octave-forge I encounter segmentation faults
and/or an error from pkg.m

For example, the 1st time I try to install 'audio-1.0.2.tar.gz', a
segmentation fault results

sudo octave
octave:1> pkg global_list
/sw/share/octave/octave_packages
octave:2> pkg('install','-nodeps','audio-1.0.2.tar.gz')
panic: Segmentation fault -- stopping myself...

When I make a second attempt, I get ...

sudo octave
octave:1> pkg('install','-nodeps','audio-1.0.2.tar.gz')
error: couldn't create packinfo directory: File exists
error: called from `pkg:copy_files' in file
/sw/share/octave/2.9.17/m/pkg/pkg.m near line 1312, column 5

The error implies that the packinfo file for the audio toolbox already
exists ... However the directory "ls /sw/share/octave/packages" is empty.

I've posted to the help-octave list.

I've been trying to isolate the segmentation fault so that I could post
more context to the Octave forums.

I've done what I can to isolate the errors. When I try to use pkg to
install the toolboxes from octave-forge I encounter segmentation faults
and/or an error from pkg.m

For example, the 1st time I try to install 'audio-1.0.2.tar.gz', a
segmentation fault results

sudo octave
octave:1> pkg global_list
/sw/share/octave/octave_packages
octave:2> pkg('install','-nodeps','audio-1.0.2.tar.gz')
panic: Segmentation fault -- stopping myself...

When I make a second attempt, I get ...

sudo octave
octave:1> pkg('install','-nodeps','audio-1.0.2.tar.gz')
error: couldn't create packinfo directory: File exists
error: called from `pkg:copy_files' in file
/sw/share/octave/2.9.17/m/pkg/pkg.m near line 1312, column 5

The error implies that the packinfo file for the audio toolbox already
exists ... However the directory "ls /sw/share/octave/packages" is empty.

I've posted to the help-octave list.

They don't rely, they pretend to depend, which is an error.
In fact, they depend only on whatever compiler is listed
under 'F77' in the beginning of /sw/bin/mkoctfile, which
is gfortran since octave swithched to gfortran

JF

JF, the octave-forge.info (unstable and the one I've attached) rely on
g95.

How are you building it? ... with or without g95?

definitely not here.
The location involved no fortran whatsoever ..
but _ as I said _ the tinyest variation in the way
a pkg is built (or used) can make the seg-fault appear here,
disappear there...
Stick pls with gfortran.
This is with the latest octave ?
Then a bug-report is needed.

JF

I switched my local octave.info file to gfortran (from g95). This is the
same file I posted a few minutes ago. Once I got around to building
octave-forge 20071014 a seg-fault occurred. I'm switching back to g95 to
see what happens.

Could mixing fortran compilers be the cause of this and the prior
seg-faults?

opps ... while trying to give a better link to the sources, I goofed it
up.

Trying again.
File Added: octave-forge.info

File Added: octave.info

File Added: octave-forge.info

You have not attached the necessary file(s).
We cannot take further action on this item until you
do so. Note: Multiple items should be attached to the same
tracker item, one at a time. Thanks!

yes _ pls delete them, and move them here...
(just like I did in the beginning with your patch)
Else it is too complicated to follow the history of
of a problem, especially for newcomers to the tracker item.

And in addition, I did refer people (as you've seen) to
this tracker item ...

JF

opps ... I've already place them on the tracker. Shall I still place them
here and have the other items deleted?

For simplity, use this tracker item _ don't create new ones !

Indeed moving to octave 2.9.17 may be the easiest solution,
and the best !

JF

ok, I've been successful installing suitesparse, octave (2.9.17), and
octave-forge (20071014) on both Intel and PPC based Macs running OS X
10.4.11.

I'll place the info files for Octave-2.9.17 and octave-forge-20071014 on
the tracker.

As time permits, I'll try to isolate the circumstances that lead to a
seg-fault for versions of octave and octave-forge in the unstable tree.

I always build as root (old habits die hard ..)

JF

ahh, you are correct! I didn't include libcsparse.a ... Although, it was
an oversight on my part, I see no need to include it.

"rm %i/lib/libcsparse.a"

because your original pkg ommited it (or ? : ommitted most of CSparse),
and CSparse is included in CXSparse _ cf
/sw/share/doc/suitesparse/CXSparse/README.txt:

This package is backward compatible with CSparse. That is, user code
that
uses CSparse may switch to using CXSparse without any changes to the user
code.
Each CXSparse function has a generic version with the same name as the
CSparse
function, and four type-specific versions. For example:

cs_add same as cs_add_di by default, but can be changed to use
UF_long
integers if user code is compiled with -DCS_LONG, and/or
can
be changed to operate on complex matrices with
-DCS_COMPLEX.

cs_di_add double/int version of cs_add
cs_dl_add double/UF_long version of cs_add
cs_ci_add complex/int version of cs_add
cs_cl_add complex/UF_long version of cs_add

The sparse matrix data structures are treated in the same way: cs, css,
csn, and csd become cs_di, cs_dis, cs_din, and cs_did for the double/int
case,
cs_cl, cs_cls, cs_cln, and cs_cld for the complex/UF_long case, and so
on.

you can check that the "generic" versions like cs_add are indeed defined
as macros
in cs.h (the right cs.h _ the one installed by the info file here)

OK ?

JF

Once I am able to confirm that I can successfully install all three
packages, I'll look for a specific sequence of events that reliably
produces the seg-fault.

Regarding your seg-faults, what was the exact command you issued. Each of
my seg-faults coincided with

fink -m --build-as-nobody rebuild octave-forge

However, thus far I'm been successful with

fink rebuild octave-forge

It may be coincidental, but I thought I'd ask.

a seg-fault is an indication of an error somewhere in compiled code.
It is very fickle _ the slightest variation can make it disappear, or
appear
somewhere else..
E.g., in the first crash log I attached, there are 2 different crashes _
looking
identical in the crash log. But the first occured almost immediately in
the build
of octave-forge (after 2 mkoctfile commands if I recall correctly), while
the second
ocurred after a large numder of mkoctfile commands. And the 2 builds of
octave
were generated by diffs in info files that I would have bet cannot
influence the deb...

So the only way to cure them is not to find ways around, but on the
contrary to preserve it
carefully and to narrow it down to smaller and smaller examples, until one
sees the error !

Another way to narrow down the problem, when one has several different
crash logs
(in /Library/Logs/CrashReporter/octave.crash.log), stemming from different
builds
or from "the same" error occuring at different places, is to compare them
and find
the "common part". So please start maybe with this, with your crash logs,
and then with
those I've posted here..
In thos I've posted, one sees there are very few cc files in liboctinterp
that reappear all
the time in the back-trace; once one has identified a small set of
potential culprits,
one canthe rebuild octave with those routines set to no optimization and
full debugging;
if this makes the problem go away, one can try dichotomy to narrow the
choices further,
and else .. try using gdb _ provided one has obtained a sufficiently
small example ...

So _ please _ do not try to avoid the seg-faults _ do try to provoke them,
in as many
different circumstances as possible, and compare the crash logs.. (in
particular,
can you generate those crashes both on ppc and on intel ?)

I did a small experiment to try narrowing down where it occurs (with my
current
"octave-atlas-2.9.14"); I changed octave-forge.info to produce more (a
diarhea of !)
information by the following diff:

47,48c47,48
< echo "pkg install *.tar.gz" >> tmp
< for d in main extra nonfree; do cd $d; octave -q ../tmp; cd -; done
---
> echo "pkg install -verbose *.tar.gz" >> tmp
> for d in main extra nonfree; do cd $d; octave -d -x -V ../tmp; cd -;
done


I see then that the seg-fault occurs at the end of the install of all
pkgs
in "main" (the first subdir visited) _ in particular, all of them are
already
completely built, thus exonerating once more octave-forge _, and it
occurs
in the execution of /sw/share/octave/2.9.14/m/pkg/pkg.m, either on line
699 global_packages = save_order ({global_packages{idx},
descriptions{:}});
or immediately after _ i.e., completely in pkg.m's internal pkg
management
operations, that use no math at all _ thus exonerating again completely
any
other pkg...

JF

JF,

Using *your* suitesparse.info, and my local octave.info and
octave-forge.info for version 2.9.17 I have been successful installing all
three packages on my Intel Mac.

I'm still wondering why your suitesparse.info includes the line below in
the InstallScript

rm %i/lib/libcsparse.a

In any event, I'm presenting rebuilding each of those packages to be
certain.

Assuming I'm successful, I'll place copies of my octave.info and
octave-forge.info files on the tracker for others who may have an
interest.

JF,

I've succeeded in producing a local octave-forge.info file that functions
on my PPC based Mac.

Everything appears to be operational when I compiled using

fink rebuild octave-forge

But it failed when I tried

fink -m --build-as-nobody rebuild octave-forge

Thus I don't think it is something is ready for releasing to the general
population of Fink users until it operates correctly in all cases.

However, if you want a copy, let me know and I'll email on to you.

In any event, I'm able to install the original SuiteSparse package, Octave
2.9.14/17, and Octave-Forge without encountering a seg-fault ... and as far
as I can tell, everything works properly.

JF, I noticed the line below in your version of suitesparse.info (part of
the InstallScript)

rm %i/lib/libcsparse.a

Why did you choose to delete this library?

JF,

On my 2nd PPC based Mac, I've installed the original SuiteSparse package,
my local Octave 2.9.17, and a local Octave-Forge. I encountered no
problems.

I may be able to "borrow" a second Intel based mac to test the same
configuration on.

JF,

I have 1 Intel and 2 PPC Macs with Fink installed. All three have had my
original version of the SuiteSparse package installed. Only the Intel has
had your version of the package.

I "removed" SuiteSparse and Octave (2.9.17) from one of the PPC Macs and
then installed Octave 2.9.14, and Octave-Forge from the unstable tree.
Everything works!

Based upon this simple experiment, I'm inclined to conclude that the
problem is either specific to Intel based Macs, to the new SuiteSparse.info
file, or a combination of the two. I hesitate to try out the new
SuiteSparse.info on one of my PPC based macs.

Instead I'll try to modify the Octave-Forge.info in order to produce a
local version that functions properly for 2.9.17.

JF, check out this thread.

http://www.nabble.com/Segmentation-Fault---Octave-Forge-tf4766608.html#a13633443

Is this the source of the problem we're seeing also?

regarding replacing head with the nuetral sed, I've already done this
using the equivalent you posted;

-----------
head -n-1<<<"$l
by
sed -e '$d'<<<"$l"
-----------

It worked for me.

For my local 2.9.17 version of Octave, I don't have a working package for
octave-forge, but will look into that when time permits.

2.9.17 is bleeding-edge stuff, but I haven't experienced any crashes.

replacing the info file with the gnu form of "head"
by one with a neutral form of "sed", for whoever
wants to try this...
(although I'm convinced the problem is purely an octave
problem, nothing to do with suitesparse...)

JF
File Added: suitesparse.info

the problems arise too with your "local"
2.9.17 version ?
And is that the latest ?

JF

same impression here ..
thats why I forwarded the problem to fink-devel,
and octave's maintainer, since I won't have time
to delve into it in the next couple of days ...

JF

same impression here ..
thats why I forwarded the problem to fink-devel,
and octave's maintainer, since I won't have time
to delve into it in the next couple of days ...

JF

oh-oh.

I'm no longer able to install octave & octave-forge on my Intel based Mac.
The install of SuiteSparse makes no difference at all.

However, I had both installed and functional just prior to beginning the
work on the SuiteSparse package ... and yet I don't recall that there has
been an update to octave or octave-forge since I began compiling
suitesparse.

I meant with your local version of 2.9.17 !
If that works well (and if 2.9.17 is the latest octave
version), it can be "finkified"..

(and don't want to post bug reports about old versions,
nor about problems I dont understand well)

Best,

JF

Q: Does the same problem occur with v. 2.9.17 of octave ?

Octave's package management changed with version 2.9.15, so there is no
quick method to install octave-forge for 2.9.15+.

There is an octave-forge.info that was intended for 2.9.15/16 on the
tracker, but it failed for unrelated reasons. Since there are many more
changes to Octave on the way, I don't expect a stable octave-forge package
for Fink anytime soon. However, if I have the time, I might do something
myself.

Regarding the problem at hand, if the problem does lie with Octave, I'm
left wondering why there is no issue with Windows (Cygwin), Linux,
DarwinPorts, etc.

However, if you are sure I encourage you to post to the Octave email
lists. There are several very knowledgeable individuals who are eager to
help out. You might search them as well. The email lists may be subscribed
to here

http://www.gnu.org/software/octave/archive.html

They can be searched here

http://www.nabble.com/Octave-f1895.html

"Regarding your hypothesis that it is a bug in octave ... I'm not so
certain,.." :
I am. Look at the crash-reporter logs _ including yours : they all
fail on the cmd "octave" _ so "octave-forge" is clean..
And all the trouble happens in a series of internal calls of liboctinterp
:
sure the problem lies in that lib _ which links neither to atlas or to
suitesparse.

Does the same problem occur with v. 2.9.17 of octave ?

(As to shell scripts, you'll get used very quickly, and I'll help you
in case of need. Try for the moment just to see that this installscript
implements exactly the logic you wanted ..)

Best,

JF

Using suitesparse form the tracker and the octave and octave-forge
packages on the unstable branch, my install of octave-forge has also failed
due to a seg-fault.

Regarding your hypothesis that it is a bug in octave ... I'm not so
certain, so for the time being I'll be focusing my attention on
octave-forge.

I'm not familiar with Fink's octave-forge package, or with which of the
octave 'toolboxes' might be incompatible with Mac OS X. So it will take me
a few days to wade though the details.

Perhaps my experience will lead me to your conclusion?

Regarding your changes to the info file, the only problem, I see, is with
my skill with shell scripts (which is lacking). Unfortunately, my lack in
this area means I'm not presently capable of maintaining it. However, I
must give credit where it is due. Your solution included a file that mine
had missed.

In any event, the more significant issue is isolating the cause of the
seg-fault. Once that is sufficiently determined, I suspect a solution will
be obvious.

comment :
"Ignoring the symbolic links, licenses, text files, ect, the only change
in
the installation was ..."

Clearly _ i didn't want to change the substance _ though I did look at
the
possible alternatives for each choice, but everytime your choice seemed
optimal,
or at least stemming from a completely consistent logic (e.g., deleting
internal headers),
to which I've no objections.

I just tried to express this logic in a script, using also the apparent
"logic"
or systematic structure of the source, so that in subsequent versions the
same logic
would apply, even if files change.

_ symbolic links : the commands making them are completely explicit
_ licenses : I should not have missed 1 ! Else tell me ..
_ text files, ect : this is the effect of the "final cleanup" _ hope you
agree ...

JF

attaching the crash-log for a true octave-atlas (2.9.14)
Obviously the thing is systematic, is a bug in octave,
and occurs, according to tiny and irrelevant variations
in octave's build, at different mkoctfile cmds in octave-forge's
build _ but always identical stack of binaries and calls ..

No time to look at this seriously in the next 2 or 3 days;
hope you find a solution before ..

JF
File Added: octave-atlas.crash_log

ok, I changed to sed, and suitesparse built without error.

After the rebuild and install I issued the command

dpkg -c
/sw/fink/dists/local/main/binary-darwin-i386/sci/suitesparse_3.0.0-1_darwin-i386.deb

Ignoring the symbolic links, licenses, text files, ect, the only change in
the installation was ...

-rw-r--r-- root/admin 82 2005-08-19 16:39
./sw/include/suitesparse/xerbla.h

I'm rebuilding Octave 2.9.17 now.

you're right
in the meantime, install e.g. coreutils-default
"as an additional builddep",
or replace eg
head -n-1<<<"$l
by
sed -e '$d'<<<"$l"

(just checked that this worked even with Apple's sed ...)

opps, I mistyped. I did not type "fink install suitesparse". What I did
was issue the command

fink -m --build-as-nobody rebuild suitesparse

JF, my attempt failed quickly.

I removed Octave, SuiteSparse, and issued a "fink cleanup".

I then replaced my local SuiteSparse.info and SuiteSparse.patch files and
issue a "fink install suitesparse.

The result is below.

cd /sw/src/fink.build/root-suitesparse-3.0.0-1/sw/share/doc/suitesparse
# replace duplicates by symlinks
for n in lesser gpl; do
l=`ls -1 {,*/}*/$n.txt`
target=`tail -n1<<<"$l"`
list=`head -n-1<<<"$l"`
for f in $list; do g=`sed -e 's,[^/]\+,..,g' -e 's,\.\.$,,'
<<<"$f"`; ln -fs $g$target $f; done
done
ls -1 {,*/}*/$n.txt
tail -n1<<<"$l"
head -n-1<<<"$l"
head: illegal line count -- -1
### execution of /var/tmp/tmp.0.fi6XAy failed, exit code 1
### execution of /var/tmp/tmp.5.V7fHSs failed, exit code 1
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-suitesparse-3.0.0-1
(Reading database ... 106869 files and directories currently installed.)
Removing fink-buildlock-suitesparse-3.0.0-1 ...
Failed: phase installing: suitesparse-3.0.0-1 failed


----

Sorry _ see now the second experiment was flawed (have to change a bit
more in octave.info)
Will repeat correctly...
(and think about what this teaches us on repeatability...)

JF

right _ was building the 3 pkgs in dep order, to make sure that the build
of octave-forge would test the new octave.

The seg-fault occurs during a cmd "octave" issued by a mkoctfile during
the build of octave-forge.
(Most mkoctfile cmds work well)

I even did the experiment in 2 different ways : the first one was with a
substantially unmodified
octave, and then I re-tried adding just to octave's config param's
"--with-blas=/sw/lib/liblapack_atlas.dylib
--with-lapack=/sw/lib/liblapack_atlas.dylib"
causing it (and hence suitesparse code) to be linked to atlas rather than
veclib.
This seg-faulted too _ although much later in the build of octave-forge.

the first experiment I did repeat, and the same seg-fault (same
CrashReporter log) occured at the same place. Didn't repeat the second, but
would expect there too.

My impression is that the thing has nothing to do with the blas nor with
suitesparse; it seems to
occur wholly within liboctinterp (which is linked to neither if I remember
correctly), and that it is just the accidents of slightly diferent builds
that cause an address to become invalid here or there..
But I'd like to be sure, and to have a real cure (not just a particular
variation that by accident
doesn't choke on the build of octave-forge).
I attach the crash logs of both experiments : they seem identical, even
though occuring at different times in the build of octave-forge..

JF
File Added: octave.crash-log

You've built Octave 2.9.14 without error, but encountered a seg-fault when
building octave-forge? ... is that correct?

I was successful in building the combination of SuiteSparse, Octave, and
Octave-forge with the original version. Were you also successful in doing
that?

... I'm just trying to determine where I should focus my attention.

What package, respecting octave-forge, is the one that produces the
seg-fault? ... or does every use of mkoctfile seg-fault?

In any event, I'm presently running Octave 2.9.17 (local package).

If mkoctfile is consistent in producing a segment fault, I'm inclined to
give it a try on 2.9.17 before removing that version and reverting to
2.9.14.

After than exercise, I'll compare the contents for the deb file for the
original SuiteSparse package and your new one. I'll start with 2.9.14, but
will also eventually want to check on 2.9.17.

As I get results, I'll post them here.

Ben

File Added: suitesparse.info

sure the questions were to you ..
Following our reply, I attach revised files dealing with the different
points.
(+ removing superfluous fields, + revising the installscript, to remove
the enumeration aspect, which made it very long and probably quite
hard to maintain)

I have however a new problem : when building octave with this, and
then octave-forge, there is an octave command (through mkoctfile)
right in the beginning of the build which seg-faults _ never had this
before with those pkgs.
It doesn't seem related to suitesparse, but still..
Can you _ and anybody else reading this thread ! _ pls do the same
test ??

JF
File Added: suitesparse.patch

JF,

I just peaked at the SuiteSparse pkg that I uploaded to the Tracker and
noticed several questions. I had received the 1st by email but the rest.
Are those questions directed to me?

If so ...

Regarding g95, I don't recall. I did start with a .info file from another
pkg. Perhaps it is a remnant/

Regarding the headers, even if there are not existing conflicts, I thought
it wise to avoid any possible conflict with packages in the future. So I
placed them in their own directory.

Regarding the optimization/compile flags, I'll defer to your expertise.
They are remnants of an experience I had with a problems producing a mex
file for Matlab ... and so they are also remnants of other work. I hadn't
notice that some were compiled with -O and others with -O3.

Regarding atlas/framework, other pkgs have version of each (octave for
example). I have a great deal of confidence in the framework solution. So
I'd be cautious about a switch to atlas. With regards to Octave, is there a
problem that "Octave" using the framework solution and "Octave-atlas" uses
atlas?

Forgot also:
don't see why the builddep on g95 is needed
And if some such builddep were needed, it
would really be important to switch it to
gfortran (i.e., "gcc42")

JF

Small additional question: any specific reason to put
the headers in a subdir of %p/include, rather than directly
there ?
(I've a rather extensive fink installation, and would
detect no conflict there)

JF

File Added: suitesparse.info

sorry _ getting myself apparently confused
between both files - hope to get it right
some time !
JF

File Added: suitesparse.patch

Attaching cosmetically cleaned up info and patch files.
(patch file unmodified, just name changed to allow for standard
info file; in info file: stupidities like re-arranging a couple
of things, getting rid of useless or confusing trailing slashes,
and of '%b': the installscript is always executed in %b _ maybe
a couple more of that style).

Thanks _ this is very well packaged : no hitch whatsoever..

But may I still ask you to look at the 2 following items :

1) optimisation flags :,
a) I see that a lot is compiled with
-O3 -fno-common -no-cpp-precomp -fexceptions
now -no-cpp-precomp is "pass\'e" and doesn't do any good,
and the "-fexceptions" , you would typycally really
try to void if possible in optimised production code..
Maybe ask upstream about the latter ?
b) But some code (at the end of the build, going into
libcsparse and libcxsparse, is compiled with just "cc -O" :
is it not worthwhile/possible to try to optimise a bit
more there ?

(I'm sorry, don't wan't to sound bugging you here, but the
challenges and uses of this type of code are e.g. in linear
programming problems where # of rows and of columns may both
be 6 digit, and optimisation is really important there..)

b) Possibility (and relative efficiency ?) of using the
atlas package instead of the Accelerate framework ?
(question partly motivated because I'm myself pondering
the same questions about the "lpsolve" pkg _ and further,
at some time it might be usefull to coordinate between
a number of pkgs in fink _ e.g., also scilab _ on a single
method)

In the meantime, I'll look into how well it works with and
how to fit this best with related fink pkgs (octave first,
but e.g. possibly also lpsolve or even scilab).

But thanks for this nice and well-done contribution !

JF Mertens
File Added: suitesparse.patch

In the future, please keep all files and additional correspondence
relating to the same pkg in the same tracker item.
Moving myself the patch file from your other submission
to here, and closing the other.

JF Mertens
File Added: SuiteSparse-3.0.0.patch