Anyway, I tried to install an ATOMS module, SIVP, by using “atomsInstall(‘SIVP’)”, and got this on Scilab’s console:
SIVP - Scilab Image and Video Processing Toolbox
Load macros
Load gateways
atomsLoad: An error occurred while loading 'SIVP-0.5.3.1-2':
link: The shared archive was not loaded: libbz2.so.1.0: cannot open shared object file: No such file or directory
Already asked on Scilab’s forums, and it seems everyone is just playing fools there, and I really don’t know why.
So I came here in hopes of finding someone who would know. I’m using obviously the 64 bit version of Scilab 5.4.0.
Any idea? Thanks.
Checked and it’s indeed installed.
Oh, received a PM on Scilab forums telling that this is a known issue… Guess it’s an innate bug of Scilab… Heck the devs…
The link editor knows how to use this. What you are installing probably includes some object files that are being linked.
The development package, “libbz2-devel” very likely has the full set of symlinks for the libbz2 libraries, as well as the header files. That’s why I suggest you install that and see if it solves your problem.
Thanks for your help. Things seem to progress a bit.
First created the symlink, then Scilab asked me for libpng12.so.0, so I just installed libpng12-0. Then it’s asking for libtiff.so.4, but the only one seemingly available is libtiff.so.5, which I have already installed.
What do I do now? If I symlink both libraries I’m afraid there will be version incompatibilities!
You can try a symlink /usr/lib64/libtiff.so.4 -> /usr/lib64/libtiff.so.5
and just see if it works.
It is an ugly hack as there is guaranteed compatibility when the version
number changes after the .so (that is one reason it is different) but
sometimes such ugly hacks just work.
The clean solution would be to file a bug against the SIVP atom, if you
can find out where it should be filed for an atom.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.2 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.2 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.2 | GMA4500
In a nutshell, I installed the png library and made symbolic links linking the libraries Scilab asked for with the ones I have installed.
This time Scilab successfully loaded the module, but when using imread(), it fails to load jpeg files saying “cannot load file.jpg”. However it does load png files. Probably it won’t load jpeg, tiff nor bz2 files due to the made hack.
I think you will need to download the sources for the atom and compile
it yourself to have proper bindings to the libraries on your system.
Whoever provides the linux binaries for that atom has used an outdated
system to create them.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.2 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.2 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.2 | GMA4500
Ok, I never did it from source before but gave it a quick try, it did
not help as it does not work.
Essentially you navigate in scilab in the source tree to where the
builder.sce is locate and invoke
exec builder.sce
that starts the compile, after that you run
exec loader.sce
to load the module. But that has also crappy dependencies on libraries
which are just not existing on the system (but no error before during
the compile step, of course on my main system all -devel pacakges for
all of the system are installed so it is not that some can be missing).
Without looking in the source code this looks like hard coded
dependencies, that is beyond what I am willing to invest into that if
the maintainers of SIVP and Scilab do not care (that is exactly one of
the reasons I gave up using it and exclusively use Scipy and Octave).
I recommend you try the scilab mailing list to find out if someone can help.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.2 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.2 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.2 | GMA4500
Well, in my case the main reason I chose Scilab on Linux was because of its “portability”, i.e., the fact that installation is just downloading the package and unzipping it, so I can run it from any of my local directories or even from a USB on another Linux rig (if there was, I’m the only “dumb” among my classmates who uses Linux…). In fact that’s how I had most of my games on Windows, that’s how I liked the most.
They say Octave is the other excellent alternative to Matlab, but back then I preferred Scilab’s portability over it…
Regarding Scipy, never heard about it before…
Overall, what I really need is a good complete Matlab alternative for Linux. I had gotten used to Scilab already, but how pity of these big details…
If you seek Matlab compatibility you are better served with Octave, it
is much more compatible than Scilab.
I do not say Scilab is bad, but I could not resist to say I had bad
experience with silently abandoned modules (aka atoms) or other similar
glitches like you see them here and also plenty of bugs in the core
system. My impression is they are more focused on windows, but that is
just my impression, not sure if that is true.
After all maybe there is some simple fix which is just beyond me at the
moment and is known on their mailing list (there is also a scilab forum).
Don’t take my comment as something which drives you away from it, one
good thing with scilab is the tightly integrated IDE (Octave lacks this,
it will get one with the next version in summer this year if the release
will not be postponed).
I just say since I have moved >90% of my numerical needs to
scipy+numpy+matplotlib+spyder I have never looked back (the rest is
programming in compiled languages), on a windows machine I just install
python(x,y) which is simply a single installer which installs all of
that at once (I barely use it, just to test that what I do on linux
works also at least on windows the same way).
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.2 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.2 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.2 | GMA4500
More focused on Windows perhaps you’re right. I tried 64-bit Scilab on Windows 7 x64 and ATOMS modules worked well indeed (and I installed 2 of them back there).
However even so it’s strange, the SIVP sources you tried are supposedly the most recent ones and they date from March 2012 (I was wrong, sorry…), according to here. Also look what date is the last compiled package from, December 2011… For a seemingly abandoned project it works well on Windows…
Oh, and look what the module author told me regarding the issues:
Putting aside the almost obvious nature of his answer just for a bit, isn’t libjpeg.so.8.0.2 newer than libjpeg.so.62? Besides, the current openSUSE version was released this year and, again, look when the latest SIVP compiled binary was released…
Am 28.04.2013 17:56, schrieb F style:
>> The package was compiled with some higher version libs
>> > than that in your computer.
>> >
>> > Since it can load png images after you installed a new PNG lib,
>> > maybe you can update your JPEG lib.
That is nonsense libjpeg 6.2 was current in some openSUSE 11.x it is
much older than what you have now, it is exactly the opposite of what
was mentioned in that answer, your libraries are too new. You can try to
find an old package for libjpeg62 and extract the so files and see if
they still work with openSUSE 12.3 , the same could be tried with
libtiff4. Maybe that will work.
But do not install that rpms if you find them, there is a chance that
the screw up your system just extract the missing so files and put them
somewhere where the system can find them /usr/local/lib64 is a godd
place for such extra things.
–
PC: oS 12.3 x86_64 | i7-2600@3.40GHz | 16GB | KDE 4.10.2 | GTX 650 Ti
ThinkPad E320: oS 12.3 x86_64 | i3@2.30GHz | 8GB | KDE 4.10.2 | HD 3000
HannsBook: oS 12.3 x86_64 | SU4100@1.3GHz | 2GB | KDE 4.10.2 | GMA4500