Quote:
|
Originally Posted by DiapDealer
This, however, makes absolutely no sense. There is no way you should HAVE to do that when building Sigil from scratch using the BuildingOnLinux document as a guide. libhunspell.so and libsigilgumbo.so should be located in /usr/local/lib/sigil, along with the sigil executable. The Sigil launch script should be in /usr/local/bin (named "sigil"). Something has gone badly wrong if you need to create those links. Are you sure you don't have pieces of two different Sigils on your system? "which sigil" from a terminal (no quotes) should return only one result (/usr/local/bin/sigil). If it returns more than one, there's a problem.
|
which sigil returns only /usr/local/bin/sigil
I do see the 2 files libhunspell.so and libsigilgumbo.so in /usr/local/lib/sigil, so they for some reason must not have been enough on my system to run Sigil. I too felt something was wrong when I had to make those links for Sigil to run, but I thought Checkinstall was the reason. I'm actually relieved that it's not.
Quote:
|
Originally Posted by DiapDealer
You really shouldn't have to link to any files whatsoever. Can you verify that you have .aff files in /usr/local/share/sigil/hunspell_dictionaries ? And that you have three files in the /usr/local/lib/sigil directory (libhunspell.so, libsigilgumbo.so and sigil)?
|
Here's what those 2 directories look like on my system.
Code:
/usr/local/share/sigil/hunspell_dictionaries$ ls
About.txt es.aff README_en_GB.txt
COPYING_GPLv2.txt es.dic README_en_US.txt
COPYING_GPLv3.txt fr.aff README_es_ANY.txt
COPYING_LGPL_v2.0.txt fr.dic README_extension_owner.txt
COPYING_LGPL_v2.1.txt hyph_de_DE.dic README_fr.txt
de_DE.aff hyph_en_GB.dic README_hyph_de.txt
de_DE.dic hyph_en_US.dic README_hyph_en_GB.txt
en_GB.aff hyph_es.dic README_hyph_en_US.txt
en_GB.dic hyph_fr.dic README_hyph_es_ANY.txt
en_US.aff license.txt README_hyph_fr.txt
en_US.dic README_de_DE_frami.txt README.txt
/usr/local/lib/sigil$ ls
libhunspell.so libsigilgumbo.so sigil
Do those directories look right?
Quote:
|
Originally Posted by DiapDealer
How are you launching Sigil, by the way? Are you typing "sigil" at a terminal, or are you using the menu entry (typically under "Office" or "Accessories")? If you're double-clicking on the sigil binary in /usr/local/lib/sigil, that could be part of the problem.
|
Oh ok, this right here was the problem. I double-clicked Sigil in the build directory just like you said
. When it didn't run, I did a ./sigil in the same directory to figure out what the problem was. The error messages mentioned those libraries, which is when I made links to the library files in my build directory and placed the links in /usr/lib, and then Sigil ran successfully. I was actually pretty happy that it ran. I'm no programmer so I figured when Sigil installed, it was to the build directory. Running the binary from /usr/local/lib/sigil directly caused the test plugin to pass all tests!
So if I'm not mistaken, the compiler first created binaries in the build directory, then copied the binaries to /usr/local/bin/sigil, right? Because that would explain why there are 2 copies of the binaries. It's actually great that it works that way. I tend to move the build directory around a lot (so I can back it up as part of another folder). If checkinstall had decided to link the temporary location of the build folder to the Sigil package, then I would be in real trouble.
Ok, so I have two last questions regarding this topic:
1. Is there a general way to uninstall programs that have been installed with make install? I used checkinstall partially because I couldn't find such a method. In fact, I couldn't even find a way to track the changes done by make install (so that I can reverse the changes manually later).
2. If I compile a newer version of a program from source and try to make install with the old version still untouched, what happens? Is this generally a good idea? I used checkinstall partially so I could get rid of all traces of the old version because I didn't know what would happen if I didn't.
Thanks