Sigil test plugin fails on Hunspell

[darkbreath]

I get these errors:

...
Verifying Hunspell Checking
Hunspell en_US affix file and dictionary Missing
Hunspell shared library found
Hunspell spellchecking works False
...

At the very end, it says this:

Failure - 2 Tests of Plugin Operations Failed

What exactly is Hunspell en_US affix file and dictionary and how can I get it installed?

Thanks.

[KevinH]

Hunspell is a spellchecking library. On linux there should be simple packages that provides the hunspell library, and sets of dictionaries for various languages you can install. That test uses the en_US spellchecking dictionary which has its own affix file (.aff) and dictionary wordlist (.dic) file.

[DiapDealer]

Building/installing Sigil from scratch should have installed the library/dictionaries for you (unless you used the -DINSTALL_BUNDLED_DICTS=0 option when building). If you installed Sigil from a repo (or built with the aforementioned cmake option), you'll need to find/install the correct hunspell dictionary package for your preferred language and distro.

hunspell-en-us would be the package for US english on Ubuntu.

As in: sudo apt-get install hunspell-en-us

It would be hunspell-en for Arch users (or hunspell-fr, or hunspell-es, or whatever).

Any of those will require the hunspell package as a dependency.

[darkbreath]

I did compile from scratch, but I did not use -DINSTALL_BUNDLED_DICTS=0. This was on Ubuntu 14.04.

hunspell-en-us package is already installed and is the latest version. What am I missing?

[DiapDealer]

Not sure. Didn't you indicate that your build passed all the plugin tests? Or was that someone else? Did you relocate Sigil's support files (/usr/local/share/sigil/ by default), or alter the launch script (/usr/local/bin/sigil) in any way?

If you went with the standard BuildingOnLinux doc, the dictionary files should be in /usr/local/share/sigil/hunspell_dictionaries and the launch script will ensure that plugins can find them.

If you changed the INSTALL_PREFIX or the SHARE_INSTALL_PREFIX cmake options before building, then the launch script should handle things correctly too.

Did you relocate some files after install (or are you not using the launch script)?

[darkbreath]

The build that passed the plugin tests was me, but on an Ubuntu 16.04 installation (this is 14.04). I haven't touched anything in /usr/local's subdirectories, but I did have to move the source folder and build folders to another location to compile and install (the directory for some reason had to have no space; if I have a folder like "Folder Name" with a space, the installation will fail). These are the only 2 folders I relocated.

I didn't use -DSHARE_INSTALL_PREFIX for sure. I tried not to use custom options when I'm having trouble just getting the default options to pass.

By the way, this may or may not be related, but I used checkinstall instead of make install because I didn't know how to uninstall after using make install; I may need to upgrade to a newer version of Sigil later. Sigil still ran though, though I had to create links to ../lib/libhunspell.so and ../lib/libsigilgumbo.so and place the links in /usr/lib. If I also have to link to other hunspell files, do let me know.

[DiapDealer]

Originally Posted by darkbreath

but I did have to move the source folder and build folders to another location to compile and install (the directory for some reason had to have no space; if I have a folder like "Folder Name" with a space, the installation will fail). These are the only 2 folders I relocated.

This shouldn't be an issue (though I probably wouldn't actually "move" the build directory if it had build pieces in it already. I'd just create a new build folder and start from scratch with a new cmake command--and delete the old build folder).

Originally Posted by darkbreath

By the way, this may or may not be related, but I used checkinstall instead of make install because I didn't know how to uninstall after using make install; I may need to upgrade to a newer version of Sigil later.

This is no problem. I've done the same before, myself. But it's been a while.

Originally Posted by darkbreath

Sigil still ran though, though I had to create links to ../lib/libhunspell.so and ../lib/libsigilgumbo.so and place the links in /usr/lib.

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.

Originally Posted by darkbreath

If I also have to link to other hunspell files, do let me know.

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)?

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.

[darkbreath]

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.

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.

/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?

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

[eschwartz]

Cmake does not provide an automatic uninstall target to go with the install target it provides, for some strange reason.
(Whereas autotools and many manually-written Makefiles, do.)

It is not such a big deal since the common way of handling software is via package managers which do that for you.
But it should not be a big deal to install a new version on top of the old version, since it will tend to overwrite everything. (And anything it doesn't overwrite, will most likely be ignored.)

[DiapDealer]

Originally Posted by darkbreath

Do those directories look right?

Yes. That looks right.

Originally Posted by darkbreath

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!

Yes. Running Sigil from the build directory is not recommended for anyone other than developers. The environment Sigil needs to run properly is not complete in the build directory. It's only a staging area for the libraries and binaries that were compiled.

After installing, the way to run Sigil is to type "sigil" at a teminal, or to use the menu entries added to your Desktop Environment's "Office" and/or "Accessories" submenus. You can usually create a shortcut on your desktop by right-clicking on one of those Sigil menu entries. Launching sigil by double clicking the /usr/local/lib/sigil/sigil file is not recommended (even if it seems to work). The launch script (/usr/local/bin/sigil) sets ceratin environment variables that are necessary to ensure the proper environment exists for Sigil and its plugin framework.

And for the record, there's no "programming" skills required for building and installing Sigil. It's all administrative tasks and knowledge of (and familiarity with) the command line. That may sound a bit picky, but there really is a difference. None of this is "programming."

Originally Posted by darkbreath

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.

Yes. See my "staging area" reference above.

Originally Posted by darkbreath

I tend to move the build directory around a lot (so I can back it up as part of another folder).

Don't do this. Unless you're a developer who wants to see the result of a quick change to the source code without compiling everything all over again, there is no reason to hang on to the contents of the build directory (with the lone exception of a single file I'll get to later). It can only confuse you--as witnessed here in this case. Delete it. When you want to upgrade, download the new source, create a new build directory and start from scratch. Compiling newer source with the existing build directory of a previous version is a recipe for disaster for those not comfortable with configuring/compiling.

Originally Posted by darkbreath

If checkinstall had decided to link the temporary location of the build folder to the Sigil package, then I would be in real trouble.

In short: it won't. Checkinstall will be bound by the same install rules as "make install." It just gives you a way to easily uninstall/reinstall the same version (but typically only on the same machine).

Originally Posted by darkbreath

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).

No there's not. Not with CMake generated makefiles, at least. But Sigil is not all that hard to uninstall manually. "Make install" creates an "install_manifest.txt" file that lists every file installed and where it was installed to (minus the Qt5 dependency files obviously). It's the one file from the build directory that a non-developer should consider hanging on to. It may look overwhelming, but it's really all two directories and three individual files that need to be removed to "uninstall" Sigil (if you installed with a standard "make, make install")

Directories:
/usr/local/lib/sigil
/usr/local/share/sigil

Files:
/usr/local/bin/sigil
/usr/local/share/applications/sigil.desktop
/usr/local/share/pixmaps/sigil.png

If you change Sigil's INSTALL_PREFIX, just replace /usr/local with the prefix you've chosen.

There's the preferences directory where settings and plugins are stored (created only after Sigil first runs on any machine), but that's not typically deleted. But you can--if you like--for a completely clean slate, by deleting the $HOME./local/share/sigil-ebook directory. The .local directory and its contents is typically hidden. I don't recommend removing the $HOME./local/share/sigil-ebook directory if you don't want to lose all of your preferences, plugins ... and plugin preferences.

Originally Posted by darkbreath

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

As eschwartz mentioned, it's typically no problem installing a new version over the old. It would only potentially be an issue if there was some sort of huge overhaul of the Sigil installation structure/location or the run environment. Not very likely (and certainly not likely without a huge warning from me to Linux users).

[darkbreath]

Originally Posted by DiapDealer

After installing, the way to run Sigil is to type "sigil" at a teminal, or to use the menu entries added to your Desktop Environment's "Office" and/or "Accessories" submenus. You can usually create a shortcut on your desktop by right-clicking on one of those Sigil menu entries. Launching sigil by double clicking the /usr/local/lib/sigil/sigil file is not recommended (even if it seems to work). The launch script (/usr/local/bin/sigil) sets ceratin environment variables that are necessary to ensure the proper environment exists for Sigil and its plugin framework.

For now, I'm running Sigil by using the shortcut from the dash, which I will drag to the desktop (it's the same thing if I run a dragged copy of it from the desktop, right?)

If I'm not supposed to run Sigil by double-clicking /usr/local/lib/sigil/sigil, how is making a link pointing to it and placing it on the desktop any different? Is there a difference between double-clicking the link (on my desktop) and double-clicking /usr/local/lib/sigil/sigil?

I was also able to run Sigil with these 2 shell scripts:

1.

#!/bin/bash

"/usr/local/lib/sigil/sigil"

2.

#!/bin/bash

sigil

I assume #2 is better, since #1 seems to just be the same as double-clicking /usr/local/lib/sigil/sigil.

[DiapDealer]

The shortcut in the dash is not pointed to /usr/local/lib/sigil/sigil (at least it shouldn't be). It's pointed at Sigil's desktop application file (/usr/local/share/applications/sigil.desktop). Which in turn invokes the Sigil launch script (/usr/local/bin/sigil).

There is no need to create another shell script to launch Sigil, so neither your #1 or #2 examples are necessary. Number two would be OK, but reduntant (nor is it the same thing as #1). The /usr/local/bin/sigil shell script is already in your PATH. It's what is being run when you type 'sigil' at a terminal, or when you click the menu item (or the desktop shortcut made from the menu item).