Binaries for SLES10

[Andreas Kuntzagk]

Hi,

I need binaries for SLES10. Does there exist a downloadable rpm
somewhere? Or has somebody managed to compile it on this platform?

regards, Andreas
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Jordi Gutiérrez Hermoso]

2009/10/20 Andreas Kuntzagk <andreas.kuntzagk@...>:
> I need binaries for SLES10. Does there exist a downloadable rpm
> somewhere? Or has somebody managed to compile it on this platform?

We had Quentin Spencer making rpms, but for Fedora, not SuSE. He
hasn't been seen around here for some time, around a year. If the
latest Fedora packages work on SuSE, try that. If not, compiling
Octave isn't that difficult.
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Andreas Kuntzagk]

Hi,

> We had Quentin Spencer making rpms, but for Fedora, not SuSE. He
> hasn't been seen around here for some time, around a year.

Fedora and Suse are quite different in many aspects so I guess that wont
work. But I will try it

> If the
> latest Fedora packages work on SuSE, try that. If not, compiling
> Octave isn't that difficult.

Unfortunately for me it is :-(
Is there a list of prerequisites somewhere?

here's my configure output:

======
Octave is now configured for x86_64-unknown-linux-gnu

   Source directory:     .
   Installation prefix:  /usr/local
   C compiler:           gcc   -Wall -W -Wshadow -Wformat -g -O2
   C++ compiler:         g++  -I/usr/include/freetype2  -Wall -W
-Wshadow -Wold-style-cast -Wformat -g -O2
   Fortran compiler:     gfortran -O
   Fortran libraries:     -L/usr/lib64/gcc/x86_64-suse-linux/4.1.2
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../.. -lz -lgfortranbegin
-lgfortran -lm
   BLAS libraries:       -llapack -lblas
   FFTW libraries:       -lfftw3 -lfftw3f
   GLPK libraries:
   UMFPACK libraries:
   AMD libraries:
   CAMD libraries:
   COLAMD libraries:
   CCOLAMD libraries:
   CHOLMOD libraries:
   CXSPARSE libraries:
   ARPACK libraries:
   QRUPDATE libraries:
   HDF5 libraries:
   CURL libraries:
   REGEX libraries:      -L/usr/lib64 -lpcre
   QHULL libraries:
   OPENGL libraries:     -lftgl -lfreetype -lz -L/usr/X11R6/lib -lGL -lGLU
   FLTK backend libs:    -L/usr/X11R6/lib64 -Wl,-rpath,/usr/X11R6/lib64
-lfltk_gl -lGLU -lGL -lfltk -lm -lXext -lX11 -lsupc++
   X11 include flags:    /usr/X11R6/include
   X11 libraries:        -L/usr/X11R6/lib64 -lX11
   CARBON libraries:
   LIBS:                 -lreadline  -lncurses -ldl -lz -lm
   Default pager:        less
   gnuplot:              gnuplot
   Magick config:

   Do internal array bounds checking:  false
   Build static libraries:             false
   Build shared libraries:             true
   Dynamic Linking:                    true (dlopen)
   Include support for GNU readline:   true
   64-bit array dims and indexing:     false

configure: WARNING: UMFPACK not found.  This will result in some lack of
functionality for sparse matrices.
configure: WARNING: qrupdate not found. The QR & Cholesky updating
functions will be slow.
configure: WARNING: AMD not found. This will result in some lack of
functionality for sparse matrices.
configure: WARNING: COLAMD not found. This will result in some lack of
functionality for sparse matrices.
configure: WARNING: CCOLAMD not found. This will result in some lack of
functionality for sparse matrices.
configure: WARNING: CHOLMOD not found. This will result in some lack of
functionality for sparse matrices.
configure: WARNING: CXSparse not found. This will result in some lack of
functionality for sparse matrices.
configure: WARNING: arpack not found. This will result in a lack of the
eigs function.
configure: WARNING: GLPK library not found.  The glpk function for
solving linear programs will be disabled.
configure: WARNING: GraphicsMagick++ config script not found.  Assuming
GraphicsMagic++ library and header files are missing, so imread will not
be fully functional
configure: WARNING: Qhull library not found --- This will result in loss
of functionality of some geometry functions.
configure:

NOTE: libraries may be skipped if a library is not found OR
       if the library on your system is missing required features.
=======


And this is the error on make:

/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/liblapack.a(classq.i):
relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../lib64/liblapack.a:
could not read symbols: Bad value
collect2: ld returned 1 exit status

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Andreas Kuntzagk]

Hi,

Jordi Gutiérrez Hermoso wrote:
> 2009/10/20 Andreas Kuntzagk <andreas.kuntzagk@...>:
>> I need binaries for SLES10. Does there exist a downloadable rpm
>> somewhere? Or has somebody managed to compile it on this platform?
>
> We had Quentin Spencer making rpms, but for Fedora, not SuSE. He
> hasn't been seen around here for some time, around a year. If the
> latest Fedora packages work on SuSE, try that.

Where can I find these packages to test?
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

tir, 20 10 2009 kl. 13:50 +0200, skrev Andreas Kuntzagk:
> Unfortunately for me it is :-(
> Is there a list of prerequisites somewhere?

At my previous just I had to use SUSE as well, and getting Octave up and
running was not a particular joyful experience. SUSE is just not very
good at packaging basic scientific libraries, so you'll have to compile
a lot of stuff yourself from scratch.

You can get some (semi-old) Octave RPM's for SUSE by searching at

  http://software.opensuse.org/search

but (at least the last time I used them) they did not come with full
functionality (no QHull and no suite-sparse as far as I remember).

I'm sorry that the answer isn't more satisfactory, but in my experience
SUSE just isn't very good for scientific work :-(

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Andreas Kuntzagk]

Hi,

> At my previous just I had to use SUSE as well, and getting Octave up and
> running was not a particular joyful experience. SUSE is just not very
> good at packaging basic scientific libraries, so you'll have to compile
> a lot of stuff yourself from scratch.

Yeah, but for this I need to find out what libraries are missing and
where to get them.

> You can get some (semi-old) Octave RPM's for SUSE by searching at
>
>   http://software.opensuse.org/search

Ok, didn't know this page before. There seems to be some 3.0.3 binaries
there. I'll try and come back with results.

> but (at least the last time I used them) they did not come with full
> functionality (no QHull and no suite-sparse as far as I remember).

Actually I don't know what functionality is required here. Have to
investigate.

> I'm sorry that the answer isn't more satisfactory, but in my experience
> SUSE just isn't very good for scientific work :-(

Unfortunately changing distro is not an option right now. This is a big
compute cluster (in production) and I can't start from scratch again.
For the next time what distro do you propose for scientific computing?

regards, Andreas
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

tir, 20 10 2009 kl. 14:33 +0200, skrev Andreas Kuntzagk:
> > At my previous just I had to use SUSE as well, and getting Octave up and
> > running was not a particular joyful experience. SUSE is just not very
> > good at packaging basic scientific libraries, so you'll have to compile
> > a lot of stuff yourself from scratch.
>
> Yeah, but for this I need to find out what libraries are missing and
> where to get them.

I think the easiest approach is just to run ./configure and see what is
reported as missing.

> Unfortunately changing distro is not an option right now. This is a big
> compute cluster (in production) and I can't start from scratch again.
> For the next time what distro do you propose for scientific computing?

Yeah, I didn't expect that you could just change distro. I think Debian
is quite good at packaging everything you need, and I get the impression
that Fedora is also quite good, but I've never used it.

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Jaroslav Hajek-2]

On Tue, Oct 20, 2009 at 2:33 PM, Andreas Kuntzagk
<andreas.kuntzagk@...> wrote:

> Hi,
>
>> At my previous just I had to use SUSE as well, and getting Octave up and
>> running was not a particular joyful experience. SUSE is just not very
>> good at packaging basic scientific libraries, so you'll have to compile
>> a lot of stuff yourself from scratch.
>
> Yeah, but for this I need to find out what libraries are missing and
> where to get them.
>
>> You can get some (semi-old) Octave RPM's for SUSE by searching at
>>
>>   http://software.opensuse.org/search
>
> Ok, didn't know this page before. There seems to be some 3.0.3 binaries
> there. I'll try and come back with results.
>
>> but (at least the last time I used them) they did not come with full
>> functionality (no QHull and no suite-sparse as far as I remember).
>
> Actually I don't know what functionality is required here. Have to
> investigate.
>
>> I'm sorry that the answer isn't more satisfactory, but in my experience
>> SUSE just isn't very good for scientific work :-(
>
> Unfortunately changing distro is not an option right now. This is a big
> compute cluster (in production) and I can't start from scratch again.
> For the next time what distro do you propose for scientific computing?
>
> regards, Andreas

We have a cluster running SUSE too, and I think I had to compile all
libs from scratch as well, except BLAS and LAPACK. OTOH, the work
needs only to be done once, and I'm routinely rebuilding Octave (to be
used by all other users) from sources every 2-4 weeks...

For a modest reward I'd be willing to do the same on your cluster :D

But seriously, compiling Octave is surely much more work, but the
result is worth it. You can use heavy compiler optimizations (we use
Intel C++ with -O3), you can link in vendor-tuned BLAS if you have it
(we use AMD's multi-threaded ACML) and most importantly, you get the
most recent sources with the latest features. Also, when a bug is
fixed, you just download and apply the patch (using mercurial that's
trivial) and rebuild, no need to wait for next release...

hth

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Andreas Kuntzagk]

I just now started again to work on this problem and ATM it fails while
linking against the static liblapack.a with this -fPIC error. I also
have a liblapack.so and it should link against this. I configured with
"--enable-shared". How do I force it to use the shared liblapack.so
(both static and shared are in same directory)

regards, Andreas

Jaroslav Hajek wrote:

> On Tue, Oct 20, 2009 at 2:33 PM, Andreas Kuntzagk
> <andreas.kuntzagk@...> wrote:
>> Hi,
>>
>>> At my previous just I had to use SUSE as well, and getting Octave up and
>>> running was not a particular joyful experience. SUSE is just not very
>>> good at packaging basic scientific libraries, so you'll have to compile
>>> a lot of stuff yourself from scratch.
>> Yeah, but for this I need to find out what libraries are missing and
>> where to get them.
>>
>>> You can get some (semi-old) Octave RPM's for SUSE by searching at
>>>
>>>   http://software.opensuse.org/search
>> Ok, didn't know this page before. There seems to be some 3.0.3 binaries
>> there. I'll try and come back with results.
>>
>>> but (at least the last time I used them) they did not come with full
>>> functionality (no QHull and no suite-sparse as far as I remember).
>> Actually I don't know what functionality is required here. Have to
>> investigate.
>>
>>> I'm sorry that the answer isn't more satisfactory, but in my experience
>>> SUSE just isn't very good for scientific work :-(
>> Unfortunately changing distro is not an option right now. This is a big
>> compute cluster (in production) and I can't start from scratch again.
>> For the next time what distro do you propose for scientific computing?
>>
>> regards, Andreas
>
> We have a cluster running SUSE too, and I think I had to compile all
> libs from scratch as well, except BLAS and LAPACK. OTOH, the work
> needs only to be done once, and I'm routinely rebuilding Octave (to be
> used by all other users) from sources every 2-4 weeks...
>
> For a modest reward I'd be willing to do the same on your cluster :D
>
> But seriously, compiling Octave is surely much more work, but the
> result is worth it. You can use heavy compiler optimizations (we use
> Intel C++ with -O3), you can link in vendor-tuned BLAS if you have it
> (we use AMD's multi-threaded ACML) and most importantly, you get the
> most recent sources with the latest features. Also, when a bug is
> fixed, you just download and apply the patch (using mercurial that's
> trivial) and rebuild, no need to wait for next release...
>
> hth
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Mário Costa]

>From my experience you will have a lot of problems compiling a static
version of octave, plus you will not be able yo add any of the
external available modules for octave, since it is required dynamic
linking, in order for those to be loaded by octave ...

I've managed to build from source a dynamic version for SLES 10,
although I was unable to use an up-to-date version of gnuplot, and
compiling that from source seems a nightmare ...

I cat tell you I've used SRPMS in one of the cluster nodes (build
node) to compile and create the rpms, some of the specs required minor
chages as they where only available for fedora or so ...

Then used the rmps created at that node to install in all the other
nodes of the cluster ...

Regards,
Mário

On Wed, Oct 28, 2009 at 3:41 PM, Andreas Kuntzagk
<andreas.kuntzagk@...> wrote:

> I just now started again to work on this problem and ATM it fails while
> linking against the static liblapack.a with this -fPIC error. I also
> have a liblapack.so and it should link against this. I configured with
> "--enable-shared". How do I force it to use the shared liblapack.so
> (both static and shared are in same directory)
>
> regards, Andreas
>
> Jaroslav Hajek wrote:
>> On Tue, Oct 20, 2009 at 2:33 PM, Andreas Kuntzagk
>> <andreas.kuntzagk@...> wrote:
>>> Hi,
>>>
>>>> At my previous just I had to use SUSE as well, and getting Octave up and
>>>> running was not a particular joyful experience. SUSE is just not very
>>>> good at packaging basic scientific libraries, so you'll have to compile
>>>> a lot of stuff yourself from scratch.
>>> Yeah, but for this I need to find out what libraries are missing and
>>> where to get them.
>>>
>>>> You can get some (semi-old) Octave RPM's for SUSE by searching at
>>>>
>>>>   http://software.opensuse.org/search
>>> Ok, didn't know this page before. There seems to be some 3.0.3 binaries
>>> there. I'll try and come back with results.
>>>
>>>> but (at least the last time I used them) they did not come with full
>>>> functionality (no QHull and no suite-sparse as far as I remember).
>>> Actually I don't know what functionality is required here. Have to
>>> investigate.
>>>
>>>> I'm sorry that the answer isn't more satisfactory, but in my experience
>>>> SUSE just isn't very good for scientific work :-(
>>> Unfortunately changing distro is not an option right now. This is a big
>>> compute cluster (in production) and I can't start from scratch again.
>>> For the next time what distro do you propose for scientific computing?
>>>
>>> regards, Andreas
>>
>> We have a cluster running SUSE too, and I think I had to compile all
>> libs from scratch as well, except BLAS and LAPACK. OTOH, the work
>> needs only to be done once, and I'm routinely rebuilding Octave (to be
>> used by all other users) from sources every 2-4 weeks...
>>
>> For a modest reward I'd be willing to do the same on your cluster :D
>>
>> But seriously, compiling Octave is surely much more work, but the
>> result is worth it. You can use heavy compiler optimizations (we use
>> Intel C++ with -O3), you can link in vendor-tuned BLAS if you have it
>> (we use AMD's multi-threaded ACML) and most importantly, you get the
>> most recent sources with the latest features. Also, when a bug is
>> fixed, you just download and apply the patch (using mercurial that's
>> trivial) and rebuild, no need to wait for next release...
>>
>> hth
>>
>
> _______________________________________________
> Help-octave mailing list
> Help-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Andreas Kuntzagk]

Hi,

> From my experience you will have a lot of problems compiling a static
> version of octave, plus you will not be able yo add any of the
> external available modules for octave, since it is required dynamic
> linking, in order for those to be loaded by octave ...

But I don't want static!!! I ran "configure --enable-shared" (also did a
  "make clean". Also the shared version of that liblapack is available
so I don't know why it compiles against the static liblapack.a
My experiences with compiling C and C++ are a little dusted (apart from
the usual "configure; make; make install") so maybe it's something stupid.

> I've managed to build from source a dynamic version for SLES 10,
> although I was unable to use an up-to-date version of gnuplot, and
> compiling that from source seems a nightmare ...
>
> I cat tell you I've used SRPMS in one of the cluster nodes (build
> node) to compile and create the rpms, some of the specs required minor
> chages as they where only available for fedora or so ...
>
> Then used the rmps created at that node to install in all the other
> nodes of the cluster ...

I don't really need rpm's since I have a /usr/local on a NFS for such
shared software.

But would you mind to send me your rpm's ? Maybe they are working for
me? Or do they have some special dependencies built in?

regards, Andreas

>
> Regards,
> Mário
>
> On Wed, Oct 28, 2009 at 3:41 PM, Andreas Kuntzagk
> <andreas.kuntzagk@...> wrote:
>> I just now started again to work on this problem and ATM it fails while
>> linking against the static liblapack.a with this -fPIC error. I also
>> have a liblapack.so and it should link against this. I configured with
>> "--enable-shared". How do I force it to use the shared liblapack.so
>> (both static and shared are in same directory)
>>
>> regards, Andreas
>>
>> Jaroslav Hajek wrote:
>>> On Tue, Oct 20, 2009 at 2:33 PM, Andreas Kuntzagk
>>> <andreas.kuntzagk@...> wrote:
>>>> Hi,
>>>>
>>>>> At my previous just I had to use SUSE as well, and getting Octave up and
>>>>> running was not a particular joyful experience. SUSE is just not very
>>>>> good at packaging basic scientific libraries, so you'll have to compile
>>>>> a lot of stuff yourself from scratch.
>>>> Yeah, but for this I need to find out what libraries are missing and
>>>> where to get them.
>>>>
>>>>> You can get some (semi-old) Octave RPM's for SUSE by searching at
>>>>>
>>>>>   http://software.opensuse.org/search
>>>> Ok, didn't know this page before. There seems to be some 3.0.3 binaries
>>>> there. I'll try and come back with results.
>>>>
>>>>> but (at least the last time I used them) they did not come with full
>>>>> functionality (no QHull and no suite-sparse as far as I remember).
>>>> Actually I don't know what functionality is required here. Have to
>>>> investigate.
>>>>
>>>>> I'm sorry that the answer isn't more satisfactory, but in my experience
>>>>> SUSE just isn't very good for scientific work :-(
>>>> Unfortunately changing distro is not an option right now. This is a big
>>>> compute cluster (in production) and I can't start from scratch again.
>>>> For the next time what distro do you propose for scientific computing?
>>>>
>>>> regards, Andreas
>>> We have a cluster running SUSE too, and I think I had to compile all
>>> libs from scratch as well, except BLAS and LAPACK. OTOH, the work
>>> needs only to be done once, and I'm routinely rebuilding Octave (to be
>>> used by all other users) from sources every 2-4 weeks...
>>>
>>> For a modest reward I'd be willing to do the same on your cluster :D
>>>
>>> But seriously, compiling Octave is surely much more work, but the
>>> result is worth it. You can use heavy compiler optimizations (we use
>>> Intel C++ with -O3), you can link in vendor-tuned BLAS if you have it
>>> (we use AMD's multi-threaded ACML) and most importantly, you get the
>>> most recent sources with the latest features. Also, when a bug is
>>> fixed, you just download and apply the patch (using mercurial that's
>>> trivial) and rebuild, no need to wait for next release...
>>>
>>> hth
>>>
>> _______________________________________________
>> Help-octave mailing list
>> Help-octave@...
>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Mário Costa]

Our system has AMD x86 64, its a 64 bit, I'm not sure about the
dependencies, I'm going to check that.

If you install in /usr/local and export via nfs, there are (dynamic)
library dependencies of octave that you will still have to install in
all nodes in order to work, or that or install them in some nfs
exported /usr/lib , or /somepath/lib and update the LD_LIBRARY_PATH,
are you taking that into account ?

2009/10/29 Andreas Kuntzagk <andreas.kuntzagk@...>:

> Hi,
>
>> From my experience you will have a lot of problems compiling a static
>> version of octave, plus you will not be able yo add any of the
>> external available modules for octave, since it is required dynamic
>> linking, in order for those to be loaded by octave ...
>
> But I don't want static!!! I ran "configure --enable-shared" (also did a
>  "make clean". Also the shared version of that liblapack is available so I
> don't know why it compiles against the static liblapack.a
> My experiences with compiling C and C++ are a little dusted (apart from the
> usual "configure; make; make install") so maybe it's something stupid.
>
>> I've managed to build from source a dynamic version for SLES 10,
>> although I was unable to use an up-to-date version of gnuplot, and
>> compiling that from source seems a nightmare ...
>>
>> I cat tell you I've used SRPMS in one of the cluster nodes (build
>> node) to compile and create the rpms, some of the specs required minor
>> chages as they where only available for fedora or so ...
>>
>> Then used the rmps created at that node to install in all the other
>> nodes of the cluster ...
>
> I don't really need rpm's since I have a /usr/local on a NFS for such shared
> software.
>
> But would you mind to send me your rpm's ? Maybe they are working for me? Or
> do they have some special dependencies built in?
>
> regards, Andreas
>
>>
>> Regards,
>> Mário
>>
>> On Wed, Oct 28, 2009 at 3:41 PM, Andreas Kuntzagk
>> <andreas.kuntzagk@...> wrote:
>>>
>>> I just now started again to work on this problem and ATM it fails while
>>> linking against the static liblapack.a with this -fPIC error. I also
>>> have a liblapack.so and it should link against this. I configured with
>>> "--enable-shared". How do I force it to use the shared liblapack.so
>>> (both static and shared are in same directory)
>>>
>>> regards, Andreas
>>>
>>> Jaroslav Hajek wrote:
>>>>
>>>> On Tue, Oct 20, 2009 at 2:33 PM, Andreas Kuntzagk
>>>> <andreas.kuntzagk@...> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> At my previous just I had to use SUSE as well, and getting Octave up
>>>>>> and
>>>>>> running was not a particular joyful experience. SUSE is just not very
>>>>>> good at packaging basic scientific libraries, so you'll have to
>>>>>> compile
>>>>>> a lot of stuff yourself from scratch.
>>>>>
>>>>> Yeah, but for this I need to find out what libraries are missing and
>>>>> where to get them.
>>>>>
>>>>>> You can get some (semi-old) Octave RPM's for SUSE by searching at
>>>>>>
>>>>>>  http://software.opensuse.org/search
>>>>>
>>>>> Ok, didn't know this page before. There seems to be some 3.0.3 binaries
>>>>> there. I'll try and come back with results.
>>>>>
>>>>>> but (at least the last time I used them) they did not come with full
>>>>>> functionality (no QHull and no suite-sparse as far as I remember).
>>>>>
>>>>> Actually I don't know what functionality is required here. Have to
>>>>> investigate.
>>>>>
>>>>>> I'm sorry that the answer isn't more satisfactory, but in my
>>>>>> experience
>>>>>> SUSE just isn't very good for scientific work :-(
>>>>>
>>>>> Unfortunately changing distro is not an option right now. This is a big
>>>>> compute cluster (in production) and I can't start from scratch again.
>>>>> For the next time what distro do you propose for scientific computing?
>>>>>
>>>>> regards, Andreas
>>>>
>>>> We have a cluster running SUSE too, and I think I had to compile all
>>>> libs from scratch as well, except BLAS and LAPACK. OTOH, the work
>>>> needs only to be done once, and I'm routinely rebuilding Octave (to be
>>>> used by all other users) from sources every 2-4 weeks...
>>>>
>>>> For a modest reward I'd be willing to do the same on your cluster :D
>>>>
>>>> But seriously, compiling Octave is surely much more work, but the
>>>> result is worth it. You can use heavy compiler optimizations (we use
>>>> Intel C++ with -O3), you can link in vendor-tuned BLAS if you have it
>>>> (we use AMD's multi-threaded ACML) and most importantly, you get the
>>>> most recent sources with the latest features. Also, when a bug is
>>>> fixed, you just download and apply the patch (using mercurial that's
>>>> trivial) and rebuild, no need to wait for next release...
>>>>
>>>> hth
>>>>
>>> _______________________________________________
>>> Help-octave mailing list
>>> Help-octave@...
>>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>>
>
>

--
Mário Costa

Laboratório Nacional de Engenharia Civil
LNEC.CTI.NTIEC
Avenida do Brasil 101
1700-066 Lisboa, Portugal
Tel : ++351 21 844 3911

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Mário Costa]

>From your suse 10 you will require these

rpm -i glibc-devel-2.4-31.2.x86_64.rpm
rpm -i gcc-4.1.0-28.4.x86_64.rpm
rpm -i gmp-4.1.4-20.2.x86_64.rpm
rpm -i gcc-fortran-4.1.0-28.4.x86_64.rpm
rpm -i gd-2.0.32-23.2.x86_64.rpm
rpm -i plotutils-2.4.1-591.2.x86_64.rpm
rpm -i gnuplot-4.0.0-20.2.x86_64.rpm

I've compiled these from source

rpm -i libhdf5_hl0-1.8.2-2.1.x86_64.rpm
rpm -i libhdf5-0-1.8.2-2.1.x86_64.rpm
rpm -i libblas3-3.1.1-2.1.x86_64.rpm
rpm -i liblapack3-3.1.1-2.1.x86_64.rpm
rpm -i fftw3-3.1.2-31.1.x86_64.rpm
rpm -i octave-3.0.3-5.2.x86_64.rpm

I can send them by email, or if you know of an ftp server I can put
there also ...
> --


2009/10/29 Mário Costa <mjscosta@...>:

> Our system has AMD x86 64, its a 64 bit, I'm not sure about the
> dependencies, I'm going to check that.
>
> If you install in /usr/local and export via nfs, there are (dynamic)
> library dependencies of octave that you will still have to install in
> all nodes in order to work, or that or install them in some nfs
> exported /usr/lib , or /somepath/lib and update the LD_LIBRARY_PATH,
> are you taking that into account ?
>
> 2009/10/29 Andreas Kuntzagk <andreas.kuntzagk@...>:
>> Hi,
>>
>>> From my experience you will have a lot of problems compiling a static
>>> version of octave, plus you will not be able yo add any of the
>>> external available modules for octave, since it is required dynamic
>>> linking, in order for those to be loaded by octave ...
>>
>> But I don't want static!!! I ran "configure --enable-shared" (also did a
>>  "make clean". Also the shared version of that liblapack is available so I
>> don't know why it compiles against the static liblapack.a
>> My experiences with compiling C and C++ are a little dusted (apart from the
>> usual "configure; make; make install") so maybe it's something stupid.
>>
>>> I've managed to build from source a dynamic version for SLES 10,
>>> although I was unable to use an up-to-date version of gnuplot, and
>>> compiling that from source seems a nightmare ...
>>>
>>> I cat tell you I've used SRPMS in one of the cluster nodes (build
>>> node) to compile and create the rpms, some of the specs required minor
>>> chages as they where only available for fedora or so ...
>>>
>>> Then used the rmps created at that node to install in all the other
>>> nodes of the cluster ...
>>
>> I don't really need rpm's since I have a /usr/local on a NFS for such shared
>> software.
>>
>> But would you mind to send me your rpm's ? Maybe they are working for me? Or
>> do they have some special dependencies built in?
>>
>> regards, Andreas
>>
>>>
>>> Regards,
>>> Mário
>>>
>>> On Wed, Oct 28, 2009 at 3:41 PM, Andreas Kuntzagk
>>> <andreas.kuntzagk@...> wrote:
>>>>
>>>> I just now started again to work on this problem and ATM it fails while
>>>> linking against the static liblapack.a with this -fPIC error. I also
>>>> have a liblapack.so and it should link against this. I configured with
>>>> "--enable-shared". How do I force it to use the shared liblapack.so
>>>> (both static and shared are in same directory)
>>>>
>>>> regards, Andreas
>>>>
>>>> Jaroslav Hajek wrote:
>>>>>
>>>>> On Tue, Oct 20, 2009 at 2:33 PM, Andreas Kuntzagk
>>>>> <andreas.kuntzagk@...> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> At my previous just I had to use SUSE as well, and getting Octave up
>>>>>>> and
>>>>>>> running was not a particular joyful experience. SUSE is just not very
>>>>>>> good at packaging basic scientific libraries, so you'll have to
>>>>>>> compile
>>>>>>> a lot of stuff yourself from scratch.
>>>>>>
>>>>>> Yeah, but for this I need to find out what libraries are missing and
>>>>>> where to get them.
>>>>>>
>>>>>>> You can get some (semi-old) Octave RPM's for SUSE by searching at
>>>>>>>
>>>>>>>  http://software.opensuse.org/search
>>>>>>
>>>>>> Ok, didn't know this page before. There seems to be some 3.0.3 binaries
>>>>>> there. I'll try and come back with results.
>>>>>>
>>>>>>> but (at least the last time I used them) they did not come with full
>>>>>>> functionality (no QHull and no suite-sparse as far as I remember).
>>>>>>
>>>>>> Actually I don't know what functionality is required here. Have to
>>>>>> investigate.
>>>>>>
>>>>>>> I'm sorry that the answer isn't more satisfactory, but in my
>>>>>>> experience
>>>>>>> SUSE just isn't very good for scientific work :-(
>>>>>>
>>>>>> Unfortunately changing distro is not an option right now. This is a big
>>>>>> compute cluster (in production) and I can't start from scratch again.
>>>>>> For the next time what distro do you propose for scientific computing?
>>>>>>
>>>>>> regards, Andreas
>>>>>
>>>>> We have a cluster running SUSE too, and I think I had to compile all
>>>>> libs from scratch as well, except BLAS and LAPACK. OTOH, the work
>>>>> needs only to be done once, and I'm routinely rebuilding Octave (to be
>>>>> used by all other users) from sources every 2-4 weeks...
>>>>>
>>>>> For a modest reward I'd be willing to do the same on your cluster :D
>>>>>
>>>>> But seriously, compiling Octave is surely much more work, but the
>>>>> result is worth it. You can use heavy compiler optimizations (we use
>>>>> Intel C++ with -O3), you can link in vendor-tuned BLAS if you have it
>>>>> (we use AMD's multi-threaded ACML) and most importantly, you get the
>>>>> most recent sources with the latest features. Also, when a bug is
>>>>> fixed, you just download and apply the patch (using mercurial that's
>>>>> trivial) and rebuild, no need to wait for next release...
>>>>>
>>>>> hth
>>>>>
>>>> _______________________________________________
>>>> Help-octave mailing list
>>>> Help-octave@...
>>>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>>>
>>
>>
>
>
>
> --

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave