Difference between revisions of "Installation troubleshooting"
m (moved Installing Apertium 3.0 to Installation Troubleshooting: This page has no installation info, only troubleshooting info) |
|||
(75 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
[[Problèmes lors de l'installation|En français]] |
|||
{{TOCD}} |
{{TOCD}} |
||
Errors which may be encountered during [[installation]] and their solutions. |
|||
==Installing== |
|||
''To be added'' |
|||
==Using== |
|||
You no longer need to specify the language pair directory, so when you've installed, just do: |
|||
==apt-get errors== |
|||
===held back packages=== |
|||
<pre>apertium-all-dev : Depends: apertium-lex-tools (>= 0.1.1~r60994) but |
|||
it is not going to be installed |
|||
</pre> |
|||
This can happen if you have another apertium-related PPA in your system, so look in /etc/apt/sources.list.d/ and check that only apertium-nightly.list is there. |
|||
===unmet dependencies=== |
|||
<pre> |
<pre> |
||
The following packages have unmet dependencies: |
|||
$ cat /tmp/whatever | apertium <direction> |
|||
apertium-all-dev : Depends: libhfst-dev (>= 3.9.2~r2756) |
|||
E: Unable to correct problems, you have held broken packages. |
|||
</pre> |
</pre> |
||
This shouldn't happen these days; but if it does, do <code>apt-cache show apertium-all-dev | grep ^Depends</code> and install the individual packages listed there instead. |
|||
==Configure / autogen.sh errors== |
|||
You can find more information in the manpages. |
|||
===../ltmain.sh not found=== |
|||
<pre> |
|||
configure.ac:115: required file `../ltmain.sh' not found |
|||
</pre> |
|||
The clue here is the "..". Autotools is looking for an auxiliary file in the parent directory of this one. This will happen if you check out one project folder inside another one (e.g. check out the lttoolbox folder inside apertium-en-es, or similar). |
|||
Solution: make a new subdirectory in your home folder and check out again there (e.g. mkdir ~/src && cd ~/src && git clone …) |
|||
==Errors== |
|||
=== |
===No package lttoolbox/apertium found=== |
||
====When running configure script for |
====When running configure script for Apertium==== |
||
You may encounter an error similar to the following, |
You may encounter an error similar to the following, |
||
Line 43: | Line 56: | ||
This is because Apertium cannot find the location where the <code>lttoolbox-3.0.pc</code> file was installed. If you have installed lttoolbox (which you should have done prior to attempting to install Apertium) in a non-standard prefix (or sometimes even <code>/usr/local</code>) the configure script will not be able to find it. |
This is because Apertium cannot find the location where the <code>lttoolbox-3.0.pc</code> file was installed. If you have installed lttoolbox (which you should have done prior to attempting to install Apertium) in a non-standard prefix (or sometimes even <code>/usr/local</code>) the configure script will not be able to find it. |
||
First find the location of this file (it should be in <code>$(PREFIX)/lib/pkgconfig</code> and then run this command: |
First find the location of this file (it should be in <code>$(PREFIX)/lib/pkgconfig</code>) and then run this command: |
||
<pre> |
<pre> |
||
Line 51: | Line 64: | ||
Replace <code>/usr/local</code> with the appropriate prefix. |
Replace <code>/usr/local</code> with the appropriate prefix. |
||
If this kind of error happens even if you have updated Apertium from the nightly.dist repository, refreshing <code> |
|||
apertium-all-dev</code> may work: |
|||
<pre> |
|||
$ sudo apt-get install apertium-all-dev |
|||
</pre> |
|||
This may happen because packages change names so <code>dist-upgrade<code> may end up removing some to maintain old dependencies, and <code>apertium-all-dev</code> is often the one to get axed which leaves the rest not upgraded. |
|||
====When running configure script for language pair data==== |
====When running configure script for language pair data==== |
||
Line 57: | Line 79: | ||
checking pkg-config is at least version 0.9.0... yes |
checking pkg-config is at least version 0.9.0... yes |
||
checking for APERTIUM... configure: error: Package |
checking for APERTIUM... configure: error: Package |
||
requirements (apertium |
requirements (apertium >= 3.0.0) were not met: |
||
No package 'apertium |
No package 'apertium' found |
||
</pre> |
</pre> |
||
Similar to when running configure script for Apertium installation, but now the <code>apertium |
Similar to when running configure script for Apertium installation, but now the <code>apertium.pc</code> is not being found. Adjust PKG_CONFIG_PATH environment variable to the correct path location. First find the location of this file (it should be in $(PREFIX)/lib/pkgconfig) and then run this command: |
||
$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig |
|||
$ export PKG_CONFIG_PATH |
|||
(Replace /usr/local if you set a --prefix when installing apertium.) |
|||
====Workaround |
====Workaround when language pairs need updated configure.ac's==== |
||
Some language pairs say that they "require" an older version of apertium. The best solution is to fix their configure.ac's so they accept the new version, but here's a quick workaround: |
|||
If you installed from SVN chances are that you got apertium-3.1 which for some (by me unknown) reason makes autogen fail |
|||
I used the following workaround: |
|||
<pre> |
<pre> |
||
cd /usr/local/lib/pkgconfig/ |
cd /usr/local/lib/pkgconfig/ |
||
Line 73: | Line 99: | ||
sudo cp apertium-3.1.pc apertium-3.0.pc |
sudo cp apertium-3.1.pc apertium-3.0.pc |
||
</pre> |
</pre> |
||
(or 3.2 or 3.3. or whatever) |
|||
--[[User:Jacob Nordfalk|Jacob Nordfalk]] 07:11, 11 October 2008 (UTC) |
|||
===mv: cannot stat 'foo-bar.mode': No such file or directory=== |
|||
If you see |
|||
<pre> |
|||
modes=`xmllint --xpath '//mode[@install="yes"]/@name' modes.xml | sed 's/ *name="\([^"]*\)"/\1.mode /g'`; \ |
|||
if test -n "$modes"; then mv $modes modes/; fi |
|||
mv: cannot stat 'sme-nob.mode': No such file or directory |
|||
make: *** [Makefile:695: modes/sme-nob.mode] Error 1 |
|||
</pre> |
|||
you may have an outdated aclocal.m4/apertium.m4. Ensure you have the newest version of apertium (sudo apt update && sudo apt upgrade) and re-run |
|||
<pre> |
|||
$ ./autogen.sh --with-lang1=../apertium-foo # etc. |
|||
</pre> |
|||
(or, if you don't want to type in all that with-lang stuff, it may be enough to just do <code>$ aclocal</code>.) |
|||
===AP_CHECK_LING not found when running configure or autogen.sh=== |
|||
<pre> |
|||
./configure: line 3124: syntax error near unexpected token `1,' |
|||
./configure: line 3124: `AP_CHECK_LING(1, apertium-bar)' |
|||
</pre> |
|||
; Explanation |
|||
The m4 macro AP_CHECK_LING was not found. It is in the file apertium.m4, installed by apertium into $prefix/share/aclocal (/usr/local/share/aclocal/ if you did not specify a prefix when installing apertium). When running autogen.sh, it should have been copied from that file to aclocal.m4 before the configure script is run. |
|||
; Typical solution |
|||
If things worked before and then suddenly stopped working, re-running <code>autogen.sh</code> should be enough to fix it. |
|||
Otherwise, '''first''', check that you have $prefix/share/aclocal/apertium.m4 (e.g. <code>ls /usr/local/share/aclocal/apertium.m4</code>). If you get "No such file or directory", do an <code>git pull</code> in apertium and make and make install. Now try autogen.sh again in the language pair. If it still doesn't find AP_CHECK_LING, you may have to tell autogen.sh where it is using one of the hacks below. |
|||
For autogen.sh to find apertium.m4, the ACLOCAL_PATH variable should be set to $prefix/share/aclocal (where $prefix is typically /usr/local). A correctly written autogen.sh script ''should'' set ACLOCAL_PATH based off your prefix (defaulting to /usr/local). If it doesn't, you can do |
|||
<pre> |
|||
ACLOCAL_PATH=/usr/local/share/aclocal:${ACLOCAL_PATH} |
|||
export ACLOCAL_PATH |
|||
</pre> |
|||
(Replace /usr/local if you set a --prefix when installing apertium; you may want to put that line in your ~/.bashrc.) |
|||
; Solution for really old operating systems: |
|||
The above might still not work if you're running an old version of aclocal that doesn't support ACLOCAL_PATH (e.g. aclocal 1.11 or sometimes aclocal-1.13, used on e.g. Ubuntu 11.10 and older). If so, you can use a line like this instead of <code>autogen.sh</code>: |
|||
<pre> |
|||
autoreconf -I/usr/local/share/aclocal -fi && ./configure --with-lang2=../../languages/apertium-bar |
|||
</pre> |
|||
replacing /usr/local for your $prefix if you installed into a prefix. |
|||
If that doesn't work, try putting a symlink to your real m4 under the /usr prefix, like this if you installed apertium to the default /usr/local prefix: |
|||
<pre> |
|||
sudo ln -s /usr/local/share/aclocal/apertium.m4 /usr/share/aclocal/apertium.m4 |
|||
</pre> |
|||
(You'll have to remove that if you ever install a new apertium-version from apt.) |
|||
===You don't have cg-proc / cg-comp installed=== |
|||
Many Apertium pairs (Welsh, Breton, Norwegian, Sámi, …) now require the [[Constraint Grammar]] package to help with disambiguation. For install instructions go [[Apertium_and_Constraint_Grammar#Installing_VISL_CG3|here]]. |
|||
===PCRE=== |
|||
<pre> |
|||
checking for pcreposix.h... no |
|||
configure: error: *** unable to locate pcreposix.h include |
|||
file *** |
|||
</pre> |
|||
You don't have the PCRE (Posix-compatible regular expressions) library header files installed, if you're in Debian or Ubuntu, do: |
|||
<pre> |
|||
# apt-get install libpcre3-dev |
|||
</pre> |
|||
on Fedora, do: |
|||
<pre> |
|||
# yum install pcre-devel |
|||
</pre> |
|||
===syntax error near unexpected token PKG_CHECK_MODULES=== |
|||
; Problem |
|||
The <code>configure</code> script cannot find the <code>PKG_CHECK_MODULES</code> macro |
|||
<pre> |
|||
checking for pcre_compile in -lpcrecpp... yes |
|||
./configure: line 19995: syntax error near unexpected token `APERTIUM,' |
|||
./configure: line 19995: `PKG_CHECK_MODULES(APERTIUM, dnl' |
|||
</pre> |
|||
or |
|||
<pre> |
|||
configure.ac:112: error: possibly undefined macro: dnl |
|||
If this token and others are legitimate, please use m4_pattern_allow. |
|||
See the Autoconf documentation. |
|||
</pre> |
|||
; Solution |
|||
Run: |
|||
<pre> |
|||
autoreconf -I/usr/local/share/aclocal && ./configure |
|||
</pre> |
|||
or, if you installed into a prefix: |
|||
<pre> |
|||
autoreconf -I"$prefix/share/aclocal" && ./configure --prefix "$prefix" |
|||
</pre> |
|||
===<code>Makefile:680: *** missing separator. Stop.</code>=== |
|||
First off, make sure you've run ./autogen.sh in both the monolingual packages and the language pair. This typically fixes it. |
|||
Don't run ./configure in apertium language data; the autogen.sh file is a wrapper around configure that sets up various paths and such before running configure for you. |
|||
(Those paths aren't so important if you installed apertium from the nightly apt-get repos, but if you installed apertium from source or something other than apt-get, then running ./configure will probably mess things up unless you also make sure you've exported PKG_CONFIG_PATH and ACLOCAL_PATH to the right directories. Probably safest just to run ./autogen.sh in apertium data directories.) |
|||
If running ./autogen.sh doesn't work, try <pre>head -680 Makefile | tail</pre> (replacing 680 for whatever line the error message gave) and see what the line says. |
|||
If it says @ap_include@, then you probably need to add AP_MKINCLUDE to configure.ac. |
|||
===invalid package name: lang2~/apertium-spa=== |
|||
May happen when running |
|||
<pre> |
|||
./autogen.sh --with-lang2=~/apertium-spa |
|||
</pre> |
|||
; Explanation |
|||
Even though your shell understands the '~' symbol to mean your home directory, it isn't understood by <code>autogen.sh</code> (well, by <code>configure</code>, really). |
|||
; Typical solution |
|||
Replace '~' with $HOME, or the full path to your user. E.g. |
|||
<pre> |
|||
./autogen.sh --with-lang2=$HOME/apertium-spa |
|||
</pre> |
|||
or |
|||
<pre> |
|||
./autogen.sh --with-lang2=/home/myusername/apertium-spa |
|||
</pre> |
|||
==Compilation errors== |
|||
===crtn.o: No such file or directory=== |
|||
<pre> |
|||
.la -rpath /usr/local/lib alphabet.lo att_compiler.lo compiler.lo compression.lo entry_token.lo expander.lo fst_processor.lo lt_locale.lo match_exe.lo match_node.lo match_state.lo node.lo pattern_list.lo regexp_compiler.lo sorted_vector.lo state.lo transducer.lo trans_exe.lo xml_parse_util.lo tmx_compiler.lo -lxml2 |
|||
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtbeginS.o .libs/alphabet.o .libs/att_compiler.o .libs/compiler.o .libs/compression.o .libs/entry_token.o .libs/expander.o .libs/fst_processor.o .libs/lt_locale.o .libs/match_exe.o .libs/match_node.o .libs/match_state.o .libs/node.o .libs/pattern_list.o .libs/regexp_compiler.o .libs/sorted_vector.o .libs/state.o .libs/transducer.o .libs/trans_exe.o .libs/xml_parse_util.o .libs/tmx_compiler.o -lxml2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtendS.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crtn.o -O3 -mtune=nocona -Wl,-soname -Wl,liblttoolbox3-3.3.so.0 -o .libs/liblttoolbox3-3.3.so.0.0.0 |
|||
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crti.o: No such file or directory |
|||
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtbeginS.o: No such file or directory |
|||
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtendS.o: No such file or directory |
|||
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crtn.o: No such file or directory |
|||
Makefile:556: recipe for target 'liblttoolbox3.la' failed |
|||
make[2]: *** [liblttoolbox3.la] Error 1 |
|||
</pre> |
|||
Try |
|||
<pre> |
|||
./autogen.sh |
|||
make |
|||
</pre> |
|||
===/bin/ld: cannot find -lapertium3=== |
|||
possible solution: use "make" instead of "make -j3" |
|||
===Command not found=== |
===Command not found=== |
||
==== |
====Error 127 when running make for language pair data==== |
||
You may encounter an error like the following when attempting to compile the language pair data (example: en-fr): |
|||
<pre> |
<pre> |
||
Line 92: | Line 284: | ||
</pre> |
</pre> |
||
This occurs because the Apertium application(s) are not on your path. Add it to your path (e.g., for BASH shell use <code>export PATH=$PATH:/usr/local/bin</code> on command line or similar in your user .bash_profile file. |
This occurs because the Apertium application(s) are not on your path. Add it to your path (e.g., for BASH shell use <code>export PATH=$PATH:/usr/local/bin</code> on command line or similar in your user .bash_profile file. (And make sure they're installed and up-to-date, see [[Installation]].) |
||
(The shell (e.g. bash) returns Error 127 on "command not found".) |
|||
===Shared libraries=== |
===Shared libraries=== |
||
Line 101: | Line 295: | ||
liblttoolbox3-3.0.so.0: cannot open shared object file: |
liblttoolbox3-3.0.so.0: cannot open shared object file: |
||
No such file or directory |
No such file or directory |
||
</pre> |
|||
or |
|||
<pre> |
|||
apertium-preprocess-transfer: error while loading shared libraries: libapertium3-3.4.so.0: cannot open shared object file: No such file or directory |
|||
</pre> |
</pre> |
||
This is because lt-comp cannot find where your liblttoolbox libs are installed. You may need to do one of several things: |
|||
First of all, at least if you're on Linux, try running "sudo ldconfig". This typically solves it. |
|||
# If you have installed it in an odd location, do: <code>export LD_LIBRARY_PATH=/path/to/weird/libdir</code> |
|||
This error is because lt-comp cannot find where your liblttoolbox libs are installed. If a simple "sudo ldconfig" didn't work, you may need to do one of several things: |
|||
# If you have installed it to some $prefix, do: <code>export LD_LIBRARY_PATH=$prefix/lib</code> |
|||
# If you have installed it in <code>/usr/local</code> |
# If you have installed it in <code>/usr/local</code> |
||
## Check to see if <code>/usr/local/lib</code> is in <code>/etc/ld.so.conf</code>, if it is, run <code>ldconfig</code> |
## Check to see if <code>/usr/local/lib</code> is in <code>/etc/ld.so.conf</code>, if it is, run <code>ldconfig</code> |
||
## If it isn't, either add <code>/usr/local/lib</code> to <code>/etc/ld.so.conf</code> and re-run <code>ldconfig</code>, or do step 1. |
## If it isn't, either add <code>/usr/local/lib</code> to <code>/etc/ld.so.conf</code> and re-run <code>ldconfig</code>, or do step 1. |
||
===Error in <code>pcre_compile</code>=== |
|||
===PCRE=== |
|||
;Error |
|||
<pre> |
<pre> |
||
apertium-preprocess-transfer apertium-es-gl.es-gl.t1x es-gl.t1x.bin |
|||
checking for pcreposix.h... no |
|||
Error: pcre_compile make[1]: *** [es-gl.t1x.bin] Error 1 |
|||
configure: error: *** unable to locate pcreposix.h include |
|||
file *** |
|||
</pre> |
</pre> |
||
;Reason |
|||
You don't have the PCRE (Posix-compatible regular expressions) library header files installed, if you're in Debian or Ubuntu, do: |
|||
Probably you have an old version of PCRE installed, or a version without unicode support. |
|||
;Solution |
|||
If you have compiled PCRE from source, remember that you need to pass the option <code>--enable-utf8</code> to the <code>configure</code> script. If you have only the binary package of your distribution installed, check the version, if it is before 7.4 then try to install an updated version. |
|||
===Warning: unsupported locale, fallback to "C""=== |
|||
If you get |
|||
<pre>Warning: unsupported locale, fallback to "C""</pre> |
|||
when running a command, it means that your installation doesn't have the required locale enabled. |
|||
Try: |
|||
<pre>export LC_ALL=C.UTF-8</pre> |
|||
That should work on all newer systems. |
|||
If you have a very old system where the above does not work, you should upgrade. |
|||
If you for some reason can't upgrade, you should reconsider your life choices before trying to generate a locale manually: |
|||
<pre>locale-gen es_ES.UTF-8 |
|||
export LC_ALL=es_ES.utf8</pre> |
|||
===‘rpl_malloc’ was not declared in this scope=== |
|||
If you get: |
|||
<pre> |
<pre> |
||
make check output |
|||
# apt-get install libpcre3-dev |
|||
apertium_destxt.o apertium_destxt.cc |
|||
apertium_destxt.cc: In function ‘void* yyalloc(yy_size_t)’: |
|||
apertium_destxt.cc:2017: error: ‘rpl_malloc’ was not declared in this scope |
|||
apertium_destxt.cc: In function ‘void* yyrealloc(void*, yy_size_t)’: |
|||
apertium_destxt.cc:2029: error: ‘rpl_realloc’ was not declared in this scope |
|||
make[1]: *** [apertium_destxt.o] Error 1 |
|||
make[1]: Leaving directory `/home/surge/Resources/apertium/apertium-3.1.0/apertium' |
|||
</pre> |
</pre> |
||
Then the best thing to do is comment out the lines: |
|||
on Fedora, do: |
|||
<pre> |
<pre> |
||
AC_FUNC_MALLOC |
|||
# yum install pcre-devel |
|||
AC_FUNC_REALLOC |
|||
</pre> |
</pre> |
||
From the <code>configure.ac</code> and then re-run <code>autogen.sh</code>. |
|||
===ldconfig fails on a Mac=== |
|||
If you're on a Mac, you don't have to run ldconfig. |
|||
===modes not generated on a Mac=== |
|||
; Problem |
|||
Everything works fine except the <code>.mode</code> files aren't being generated. |
|||
; Solution |
|||
Check that you've installed <code>gawk</code> (<code>sudo port install gawk</code>) |
|||
===endian_double_util.cc:38: error: ‘fread_unlocked’ was not declared in this scope=== |
|||
Either change the code to use fread instead of fread_unlocked (the latter is just faster), |
|||
or, do this when compiling: |
|||
CPPFLAGS=" -Dfread_unlocked=fread " ./autogen.sh && make && sudo make install |
|||
=== Macports pcre conflict with Homebrew === |
|||
If you use homebrew as well as macports, you might get an error like |
|||
<pre>dyld: Symbol not found: _pcre_free</pre> |
|||
from apertium-preprocess-transfer |
|||
In that case, it's likely that apertium is using the wrong pcre. |
|||
Possible solution: <code>export LD_LIBRARY_PATH=/opt/local/lib</code> and reconfigure/recompile apertium/lttoolbox. |
|||
===xmllint or xsltproc segfaults=== |
|||
This happens on CentOS 6.5 with libxml version 20706: |
|||
<pre> |
|||
/usr/local/bin/apertium-validate-dictionary: line 14: 28504 Segmentation fault /usr/bin/xmllint --dtdvalid /usr/local/share/lttoolbox/dix.dtd --noout $FILE1 |
|||
</pre> |
|||
;possible solution: the update of the libxml2 to the 2.9.1 version made it all work |
|||
=== ISO C++1z does not allow 'register' storage=== |
|||
Newer version of c++ (c++1z/c++17) no longer supports usage of the <code>register</code> keyword. <code>Register</code> was orginally used to hint to the compiler to place a variable in a register for faster access, but most compilers today ignore that hint and decide for themselves. <br> |
|||
The keyword is still present in apertium core. |
|||
Manually (using search-and-replace) removing the keyword works... |
|||
==Runtime errors== |
|||
===<code>Error: Unknown error matching regexp (code -16)</code>=== |
|||
; Explanation |
|||
The transfer files were compiled with one version of PCRE, then libpcre was updated and now the transfer files are no longer compatible with your new libpcre version. This only happens if you're running an old version of Apertium. |
|||
; Typical solution |
|||
First of all, upgrade your Apertium installation. Then, in the language pair, do |
|||
<pre>touch -c *t?x trules-*.xml && make</pre> |
|||
(and optionally "make install" or "sudo make install") |
|||
If that doesn't work, a full remake should (but will be slower): |
|||
<pre>make clean && make</pre> |
|||
(and optionally "make install" or "sudo make install"). |
|||
===<code>Conversion error</code>=== |
|||
The above [[#Error:_Unknown_error_matching_regexp_.28code_-16.29]] problem is now fixed in Apertium. However, files that were compiled before the patch was applied are not readable after the patch is applied. |
|||
If you compiled the package yourself, the solution is to (hopefully for the last time now!) recompile the transfer files: |
|||
<pre>touch -c *t?x trules-*.xml && make</pre> |
|||
(and optionally "make install" or "sudo make install") |
|||
If you installed a language pair package (for example using apt-get), you should reinstall, making sure you reinstall the newest available package. See [[Installation]]. |
|||
===Missing pair=== |
===Missing pair=== |
||
Line 150: | Line 466: | ||
and the steps you took to compile apertium to the apertium-stuff mailing list. |
and the steps you took to compile apertium to the apertium-stuff mailing list. |
||
===apertium-tagger hanging with 100 % cpu, eating memory=== |
|||
[[Category:Installation|Apertium 3.0]] |
|||
This can happen if you don't have a UTF-8 locale, reproducible on Arch Linux with e.g. |
|||
<pre> |
|||
echo '^cows/cow<n><pl>/cow<vblex><pres>$ ^have/have<vbhaver><pres>$' |LC_ALL=C apertium-tagger -g eng-sco.prob |
|||
</pre> |
|||
The solution is to use a UTF-8 locale. Do <pre>locale -a | grep -i utf</pre> to see what your installed locales are. If you have e.g. en_GB.UTF-8 installed, you can do <pre>echo 'LANG=en_GB.UTF-8; export LANG' >>~/.bashrc</pre> and open a new terminal, you should now be running with the en_GB.UTF-8 locale. |
|||
===You don't have cg-proc installed=== |
|||
Apertium for Welsh now requires this constraint grammar package to help with disambiguation. For install instructions go [[Apertium_and_Constraint_Grammar#Installing_VISL_CG3|here]] |
|||
===Shared libraries=== |
|||
[[Category:Installation]] |
|||
<pre> |
|||
[[Category:Troubleshooting]] |
|||
lt-comp: error while loading shared libraries: liblttoolbox3-3.0.so.0: cannot |
|||
[[Category:Documentation in English]] |
|||
open shared object file: No such file or directory |
|||
</pre> |
|||
This is because lt-comp cannot find where your liblttoolbox libs are installed. You may need to do one of several things: |
|||
# If you have installed it in an odd location, do: <code>export LD_LIBRARY_PATH=/path/to/weird/libdir</code> |
|||
# If you have installed it in <code>/usr/local</code> |
|||
## Check to see if <code>/usr/local/lib</code> is in <code>/etc/ld.so.conf</code>, if it is, run <code>ldconfig</code> |
|||
## If it isn't, either add <code>/usr/local/lib</code> to <code>/etc/ld.so.conf</code> and re-run <code>ldconfig</code>, or do step 1. |
Latest revision as of 08:13, 24 May 2019
Errors which may be encountered during installation and their solutions.
apt-get errors[edit]
held back packages[edit]
apertium-all-dev : Depends: apertium-lex-tools (>= 0.1.1~r60994) but it is not going to be installed
This can happen if you have another apertium-related PPA in your system, so look in /etc/apt/sources.list.d/ and check that only apertium-nightly.list is there.
unmet dependencies[edit]
The following packages have unmet dependencies: apertium-all-dev : Depends: libhfst-dev (>= 3.9.2~r2756) E: Unable to correct problems, you have held broken packages.
This shouldn't happen these days; but if it does, do apt-cache show apertium-all-dev | grep ^Depends
and install the individual packages listed there instead.
Configure / autogen.sh errors[edit]
../ltmain.sh not found[edit]
configure.ac:115: required file `../ltmain.sh' not found
The clue here is the "..". Autotools is looking for an auxiliary file in the parent directory of this one. This will happen if you check out one project folder inside another one (e.g. check out the lttoolbox folder inside apertium-en-es, or similar).
Solution: make a new subdirectory in your home folder and check out again there (e.g. mkdir ~/src && cd ~/src && git clone …)
No package lttoolbox/apertium found[edit]
When running configure script for Apertium[edit]
You may encounter an error similar to the following, the particular packages in error may differ (i.e., the error list here was on Mandriva Linux 2009).
checking pkg-config is at least version 0.9.0... yes checking for APERTIUM... configure: error: Package requirements (lttoolbox-3.0 >= 3.0.0 libxml-2.0 >= 2.6.17 libpcre >= 6.4) were not met: No package 'lttoolbox-3.0' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables APERTIUM_CFLAGS and APERTIUM_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
This is because Apertium cannot find the location where the lttoolbox-3.0.pc
file was installed. If you have installed lttoolbox (which you should have done prior to attempting to install Apertium) in a non-standard prefix (or sometimes even /usr/local
) the configure script will not be able to find it.
First find the location of this file (it should be in $(PREFIX)/lib/pkgconfig
) and then run this command:
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
Replace /usr/local
with the appropriate prefix.
If this kind of error happens even if you have updated Apertium from the nightly.dist repository, refreshing
apertium-all-dev
may work:
$ sudo apt-get install apertium-all-dev
This may happen because packages change names so dist-upgrade
may end up removing some to maintain old dependencies, and
apertium-all-dev
is often the one to get axed which leaves the rest not upgraded.
When running configure script for language pair data[edit]
checking pkg-config is at least version 0.9.0... yes
checking for APERTIUM... configure: error: Package
requirements (apertium >= 3.0.0) were not met:
No package 'apertium' found
Similar to when running configure script for Apertium installation, but now the apertium.pc
is not being found. Adjust PKG_CONFIG_PATH environment variable to the correct path location. First find the location of this file (it should be in $(PREFIX)/lib/pkgconfig) and then run this command:
$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
$ export PKG_CONFIG_PATH
(Replace /usr/local if you set a --prefix when installing apertium.)
Workaround when language pairs need updated configure.ac's[edit]
Some language pairs say that they "require" an older version of apertium. The best solution is to fix their configure.ac's so they accept the new version, but here's a quick workaround:
cd /usr/local/lib/pkgconfig/
sudo cp lttoolbox-3.1.pc lttoolbox-3.0.pc
sudo cp apertium-3.1.pc apertium-3.0.pc
(or 3.2 or 3.3. or whatever)
mv: cannot stat 'foo-bar.mode': No such file or directory[edit]
If you see
modes=`xmllint --xpath '//mode[@install="yes"]/@name' modes.xml | sed 's/ *name="\([^"]*\)"/\1.mode /g'`; \
if test -n "$modes"; then mv $modes modes/; fi
mv: cannot stat 'sme-nob.mode': No such file or directory
make: *** [Makefile:695: modes/sme-nob.mode] Error 1
you may have an outdated aclocal.m4/apertium.m4. Ensure you have the newest version of apertium (sudo apt update && sudo apt upgrade) and re-run
$ ./autogen.sh --with-lang1=../apertium-foo # etc.
(or, if you don't want to type in all that with-lang stuff, it may be enough to just do $ aclocal
.)
AP_CHECK_LING not found when running configure or autogen.sh[edit]
./configure: line 3124: syntax error near unexpected token `1,'
./configure: line 3124: `AP_CHECK_LING(1, apertium-bar)'
- Explanation
The m4 macro AP_CHECK_LING was not found. It is in the file apertium.m4, installed by apertium into $prefix/share/aclocal (/usr/local/share/aclocal/ if you did not specify a prefix when installing apertium). When running autogen.sh, it should have been copied from that file to aclocal.m4 before the configure script is run.
- Typical solution
If things worked before and then suddenly stopped working, re-running autogen.sh
should be enough to fix it.
Otherwise, first, check that you have $prefix/share/aclocal/apertium.m4 (e.g. ls /usr/local/share/aclocal/apertium.m4
). If you get "No such file or directory", do an git pull
in apertium and make and make install. Now try autogen.sh again in the language pair. If it still doesn't find AP_CHECK_LING, you may have to tell autogen.sh where it is using one of the hacks below.
For autogen.sh to find apertium.m4, the ACLOCAL_PATH variable should be set to $prefix/share/aclocal (where $prefix is typically /usr/local). A correctly written autogen.sh script should set ACLOCAL_PATH based off your prefix (defaulting to /usr/local). If it doesn't, you can do
ACLOCAL_PATH=/usr/local/share/aclocal:${ACLOCAL_PATH}
export ACLOCAL_PATH
(Replace /usr/local if you set a --prefix when installing apertium; you may want to put that line in your ~/.bashrc.)
- Solution for really old operating systems
The above might still not work if you're running an old version of aclocal that doesn't support ACLOCAL_PATH (e.g. aclocal 1.11 or sometimes aclocal-1.13, used on e.g. Ubuntu 11.10 and older). If so, you can use a line like this instead of autogen.sh
:
autoreconf -I/usr/local/share/aclocal -fi && ./configure --with-lang2=../../languages/apertium-bar
replacing /usr/local for your $prefix if you installed into a prefix.
If that doesn't work, try putting a symlink to your real m4 under the /usr prefix, like this if you installed apertium to the default /usr/local prefix:
sudo ln -s /usr/local/share/aclocal/apertium.m4 /usr/share/aclocal/apertium.m4
(You'll have to remove that if you ever install a new apertium-version from apt.)
You don't have cg-proc / cg-comp installed[edit]
Many Apertium pairs (Welsh, Breton, Norwegian, Sámi, …) now require the Constraint Grammar package to help with disambiguation. For install instructions go here.
PCRE[edit]
checking for pcreposix.h... no
configure: error: *** unable to locate pcreposix.h include
file ***
You don't have the PCRE (Posix-compatible regular expressions) library header files installed, if you're in Debian or Ubuntu, do:
# apt-get install libpcre3-dev
on Fedora, do:
# yum install pcre-devel
syntax error near unexpected token PKG_CHECK_MODULES[edit]
- Problem
The configure
script cannot find the PKG_CHECK_MODULES
macro
checking for pcre_compile in -lpcrecpp... yes
./configure: line 19995: syntax error near unexpected token `APERTIUM,'
./configure: line 19995: `PKG_CHECK_MODULES(APERTIUM, dnl'
or
configure.ac:112: error: possibly undefined macro: dnl
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
- Solution
Run:
autoreconf -I/usr/local/share/aclocal && ./configure
or, if you installed into a prefix:
autoreconf -I"$prefix/share/aclocal" && ./configure --prefix "$prefix"
Makefile:680: *** missing separator. Stop.
[edit]
First off, make sure you've run ./autogen.sh in both the monolingual packages and the language pair. This typically fixes it.
Don't run ./configure in apertium language data; the autogen.sh file is a wrapper around configure that sets up various paths and such before running configure for you.
(Those paths aren't so important if you installed apertium from the nightly apt-get repos, but if you installed apertium from source or something other than apt-get, then running ./configure will probably mess things up unless you also make sure you've exported PKG_CONFIG_PATH and ACLOCAL_PATH to the right directories. Probably safest just to run ./autogen.sh in apertium data directories.)
If running ./autogen.sh doesn't work, try
head -680 Makefile | tail
(replacing 680 for whatever line the error message gave) and see what the line says.
If it says @ap_include@, then you probably need to add AP_MKINCLUDE to configure.ac.
invalid package name: lang2~/apertium-spa[edit]
May happen when running
./autogen.sh --with-lang2=~/apertium-spa
- Explanation
Even though your shell understands the '~' symbol to mean your home directory, it isn't understood by autogen.sh
(well, by configure
, really).
- Typical solution
Replace '~' with $HOME, or the full path to your user. E.g.
./autogen.sh --with-lang2=$HOME/apertium-spa
or
./autogen.sh --with-lang2=/home/myusername/apertium-spa
Compilation errors[edit]
crtn.o: No such file or directory[edit]
.la -rpath /usr/local/lib alphabet.lo att_compiler.lo compiler.lo compression.lo entry_token.lo expander.lo fst_processor.lo lt_locale.lo match_exe.lo match_node.lo match_state.lo node.lo pattern_list.lo regexp_compiler.lo sorted_vector.lo state.lo transducer.lo trans_exe.lo xml_parse_util.lo tmx_compiler.lo -lxml2
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtbeginS.o .libs/alphabet.o .libs/att_compiler.o .libs/compiler.o .libs/compression.o .libs/entry_token.o .libs/expander.o .libs/fst_processor.o .libs/lt_locale.o .libs/match_exe.o .libs/match_node.o .libs/match_state.o .libs/node.o .libs/pattern_list.o .libs/regexp_compiler.o .libs/sorted_vector.o .libs/state.o .libs/transducer.o .libs/trans_exe.o .libs/xml_parse_util.o .libs/tmx_compiler.o -lxml2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtendS.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crtn.o -O3 -mtune=nocona -Wl,-soname -Wl,liblttoolbox3-3.3.so.0 -o .libs/liblttoolbox3-3.3.so.0.0.0
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crti.o: No such file or directory
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtbeginS.o: No such file or directory
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/crtendS.o: No such file or directory
g++: error: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/crtn.o: No such file or directory
Makefile:556: recipe for target 'liblttoolbox3.la' failed
make[2]: *** [liblttoolbox3.la] Error 1
Try
./autogen.sh
make
/bin/ld: cannot find -lapertium3[edit]
possible solution: use "make" instead of "make -j3"
Command not found[edit]
Error 127 when running make for language pair data[edit]
You may encounter an error like the following when attempting to compile the language pair data (example: en-fr):
$ make
make all-am
make[1]: Entering directory `/<path>/apertium-en-fr'
apertium-validate-dictionary apertium-en-fr.en.dixtmp1
make[1]: apertium-validate-dictionary: Command not found
make[1]: *** [en-fr.automorf.bin] Error 127
make[1]: Leaving directory `/<path>/apertium-en-fr'
make: *** [all] Error 2
This occurs because the Apertium application(s) are not on your path. Add it to your path (e.g., for BASH shell use export PATH=$PATH:/usr/local/bin
on command line or similar in your user .bash_profile file. (And make sure they're installed and up-to-date, see Installation.)
(The shell (e.g. bash) returns Error 127 on "command not found".)
[edit]
lt-comp: error while loading shared libraries:
liblttoolbox3-3.0.so.0: cannot open shared object file:
No such file or directory
or
apertium-preprocess-transfer: error while loading shared libraries: libapertium3-3.4.so.0: cannot open shared object file: No such file or directory
First of all, at least if you're on Linux, try running "sudo ldconfig". This typically solves it.
This error is because lt-comp cannot find where your liblttoolbox libs are installed. If a simple "sudo ldconfig" didn't work, you may need to do one of several things:
- If you have installed it to some $prefix, do:
export LD_LIBRARY_PATH=$prefix/lib
- If you have installed it in
/usr/local
- Check to see if
/usr/local/lib
is in /etc/ld.so.conf
, if it is, run ldconfig
- If it isn't, either add
/usr/local/lib
to /etc/ld.so.conf
and re-run ldconfig
, or do step 1.
Error in pcre_compile
[edit]
- Error
apertium-preprocess-transfer apertium-es-gl.es-gl.t1x es-gl.t1x.bin
Error: pcre_compile make[1]: *** [es-gl.t1x.bin] Error 1
- Reason
Probably you have an old version of PCRE installed, or a version without unicode support.
- Solution
If you have compiled PCRE from source, remember that you need to pass the option --enable-utf8
to the configure
script. If you have only the binary package of your distribution installed, check the version, if it is before 7.4 then try to install an updated version.
Warning: unsupported locale, fallback to "C""[edit]
If you get
Warning: unsupported locale, fallback to "C""
when running a command, it means that your installation doesn't have the required locale enabled.
Try:
export LC_ALL=C.UTF-8
That should work on all newer systems.
If you have a very old system where the above does not work, you should upgrade.
If you for some reason can't upgrade, you should reconsider your life choices before trying to generate a locale manually:
locale-gen es_ES.UTF-8
export LC_ALL=es_ES.utf8
‘rpl_malloc’ was not declared in this scope[edit]
If you get:
make check output
apertium_destxt.o apertium_destxt.cc
apertium_destxt.cc: In function ‘void* yyalloc(yy_size_t)’:
apertium_destxt.cc:2017: error: ‘rpl_malloc’ was not declared in this scope
apertium_destxt.cc: In function ‘void* yyrealloc(void*, yy_size_t)’:
apertium_destxt.cc:2029: error: ‘rpl_realloc’ was not declared in this scope
make[1]: *** [apertium_destxt.o] Error 1
make[1]: Leaving directory `/home/surge/Resources/apertium/apertium-3.1.0/apertium'
Then the best thing to do is comment out the lines:
AC_FUNC_MALLOC
AC_FUNC_REALLOC
From the configure.ac
and then re-run autogen.sh
.
ldconfig fails on a Mac[edit]
If you're on a Mac, you don't have to run ldconfig.
modes not generated on a Mac[edit]
- Problem
Everything works fine except the .mode
files aren't being generated.
- Solution
Check that you've installed gawk
(sudo port install gawk
)
endian_double_util.cc:38: error: ‘fread_unlocked’ was not declared in this scope[edit]
Either change the code to use fread instead of fread_unlocked (the latter is just faster),
or, do this when compiling:
CPPFLAGS=" -Dfread_unlocked=fread " ./autogen.sh && make && sudo make install
Macports pcre conflict with Homebrew[edit]
If you use homebrew as well as macports, you might get an error like
dyld: Symbol not found: _pcre_free
from apertium-preprocess-transfer
In that case, it's likely that apertium is using the wrong pcre.
Possible solution: export LD_LIBRARY_PATH=/opt/local/lib
and reconfigure/recompile apertium/lttoolbox.
xmllint or xsltproc segfaults[edit]
This happens on CentOS 6.5 with libxml version 20706:
/usr/local/bin/apertium-validate-dictionary: line 14: 28504 Segmentation fault /usr/bin/xmllint --dtdvalid /usr/local/share/lttoolbox/dix.dtd --noout $FILE1
- possible solution
- the update of the libxml2 to the 2.9.1 version made it all work
ISO C++1z does not allow 'register' storage[edit]
Newer version of c++ (c++1z/c++17) no longer supports usage of the register
keyword. Register
was orginally used to hint to the compiler to place a variable in a register for faster access, but most compilers today ignore that hint and decide for themselves.
The keyword is still present in apertium core.
Manually (using search-and-replace) removing the keyword works...
Runtime errors[edit]
Error: Unknown error matching regexp (code -16)
[edit]
- Explanation
The transfer files were compiled with one version of PCRE, then libpcre was updated and now the transfer files are no longer compatible with your new libpcre version. This only happens if you're running an old version of Apertium.
- Typical solution
First of all, upgrade your Apertium installation. Then, in the language pair, do
touch -c *t?x trules-*.xml && make
(and optionally "make install" or "sudo make install")
If that doesn't work, a full remake should (but will be slower):
make clean && make
(and optionally "make install" or "sudo make install").
Conversion error
[edit]
The above #Error:_Unknown_error_matching_regexp_.28code_-16.29 problem is now fixed in Apertium. However, files that were compiled before the patch was applied are not readable after the patch is applied.
If you compiled the package yourself, the solution is to (hopefully for the last time now!) recompile the transfer files:
touch -c *t?x trules-*.xml && make
(and optionally "make install" or "sudo make install")
If you installed a language pair package (for example using apt-get), you should reinstall, making sure you reinstall the newest available package. See Installation.
Missing pair[edit]
$ echo "Eso es un test" | apertium es-ca
Error: Mode es-ca does not exist. Try one of:
README
Looks like you don't have any language pairs installed, did you run make install
in the language pair directory?
If you did, email the output of
$ cat /usr/local/bin/apertium | grep -e APERTIUM -e DEFAULT
...obviously replace /usr/local/bin/apertium with the location of the $(prefix)/bin/apertium
and the steps you took to compile apertium to the apertium-stuff mailing list.
apertium-tagger hanging with 100 % cpu, eating memory[edit]
This can happen if you don't have a UTF-8 locale, reproducible on Arch Linux with e.g.
echo '^cows/cow<n><pl>/cow<vblex><pres>$ ^have/have<vbhaver><pres>$' |LC_ALL=C apertium-tagger -g eng-sco.prob
The solution is to use a UTF-8 locale. Do
locale -a | grep -i utf
to see what your installed locales are. If you have e.g. en_GB.UTF-8 installed, you can do
echo 'LANG=en_GB.UTF-8; export LANG' >>~/.bashrc
and open a new terminal, you should now be running with the en_GB.UTF-8 locale.