Hi Knudfl

Thks for the hint... :-)

I Know the dangers of "bad behaviour" under /root...

In Fact, I am equally used to distros that by default allow root logins ( RHELs Fedoras SUSEs ) and those that do not... ( Debians *buntus... )

I Only log as root when I am performing administrator tasks like Installing applications and/or libraries, which is what I was doing, trying to install all these apps I mentioned... Scilab, Paraview, Salome-Platform, in case the build fails, my system remanins untouched, because I never "make install" something that is not really needed... and even if I do so, I can always "make uninstall" before "make clean" and simply rm -rfing the "trashy" build source tree...

I tried to build UMFPACK, but since the build failed, I tried to compile and make Scilab without resorting to UMFPACK (--without-umfpack configure option ) for instance...

In case I follow these rules when being /root, is there any possible harm to my system... ?

...Note that for my everyday work I onlt touch in /home/alex/* and /tmp... nothing else... but when trying to "populate" my system with the apps that I need... I think it is more practical to do it as /root... ( Debian's use a root shell under a user accout to do this... But I guess that in the end it all ammounts to the same... when launching a script, or typing something in root shell, one is GOD... :-) and must be very responsible for what he does... )

What is your opinion on this...?

About paraview and the cmake build... this is not a Slackware issue.... Slackware's cmake successfully built Qt-Octave's SlackBuild, which is a cmake build...

I have tried to build Paraview-3.6.1 as well as P. 3.4.x... in a CentOS 5.4 x86_64. and the results were the same... :-(

Thing is I am adept of compiling the stuff, not installing the precompiled binaries... I can fine tune the performance of the applications with the compilation options, with precompiled stuff i am not... :-(

BRGDS

Alex

UMFPACK used to be easy to build ..

The latest UMFPACK
http://www.cise.ufl.edu/research/spa...UMFPACK.tar.gz
.. and UFconfig , required ..
http://www.cise.ufl.edu/research/spa...Fconfig.tar.gz
.. AMD , required ..
http://www.cise.ufl.edu/research/spa...ent/AMD.tar.gz

Unpack all three to e.g. /home/"name"/tmp/ .. and : cd UMFPACK/
.. then 'make' .. but :

To build : The 'libg2c.a' from the old gcc-3.x-g77 is required.
http://connie.slackware.com/~alien/s...cc34/pkg/12.0/
The "compat" gcc34 from alien slackbuilds .. no F77 , no libg2c
.. but this one usually works ..
http://mirror.centos.org/centos/5.4/...4.6-4.i386.rpm
# rpm2tgz compat-gcc-34-g77-3.4.6-4.i386.rpm .. and # installpkg ..
cd /usr/lib/ , # ln -s gcc/i386-redhat-linux/3.4.6/libg2c.a
.. or don't install the package, just copy libg2c.a to /usr/lib/ .

'make' will now run with no errors on Slackware 13.
Except for this : "" make[1]: [run] Error 1 (ignored) ""
.....

Downgrading python to 2.5 will require rebuilding lots of the system - any other package that installs python modules will have to be rebuilt. It's certainly possible, and don't take this the wrong way, but it doesn't sound like an endeavor that you need to pursue at your current level of knowledge.

Thks Rworkman and Knudfl

BRGDS

Alex

Instead of downgrade python, why don't you evaluate an alternate install of python 2.5 (if Salome needs at least 2.3.5, so python 2.6 shouldn't be ok?).

There is nothing wrong to have multiple python versions on your system. Just pay attention when you start your script to use the right interpreter (e.g. python2.5 script.py)

Hi Xcristy

So you mean that I can installpkg some older python from slackbuilds call it the 2.5.x, and change the runInstall script od Salome... ?

Nice, but, since most salome operations are performed using the python interpreter, how do I set some python environment ( probably sourcing the salome environment ) so that it finds the Python 2.5 instead of the Python 2.6.2...?

It must "feel" the Python to be 2.5....

How do I set the Python version in the environment script...?

PS: I have checked the /opt/salome/KERNEL_5.1.2/salome.sh which sources the environment in my Lenny box, and there is no reference to any version of Python whatsoever... it just assumes that one has the required version installed...

.... sooo... my approach would be something like

# echo 'export PYTHON_whatsoever=MY_Python&& . /opt/salome/KERNEL_5.1.2/salome.sh&&/opt/salome/KERNEL_5.1.2/bin/runSalome' > /usr/local/bin/salome&&chmod +x /usr/local/bin/salome

...But I am quite sure that the way to choose the version of python to be used is not with export...

...How is it done...?

BRGDS

Alex

cd /usr/bin
su
mv python python_backup
.. to save your python(2.6) from overwriting.
installpkg python-2.5--------
rm python
mv python_backup python

Then 'python' is "python version 2.6" again.
.. 'python2.5 file.py' will of course work with
version 2.5 and use files in /usr/lib/python2.5/

If you want / have to use the command python in some
application using python2.5, just make a "start script"
for that application : script = abc or abc.sh to start abc ..
line 1 : #!/bin/sh
line 2 : python2.5 abc.py
... or if the application already has a start script, then
just edit python to python2.5 in that script.
.....

May be this is more correct . Both versions work ...
... With or without the ' exec ' ...