Re: Binaries for SLES10

[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 <address@hidden>:
> 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 <address@hidden>:
>> 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
>>> <address@hidden> 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
>>>>> <address@hidden> 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
>>>> address@hidden
>>>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>>>
>>
>>
>
>
>
> --