Difference between revisions of "Installation troubleshooting"
Line 407: | Line 407: | ||
===apertium-tagger hanging with 100 % cpu, eating memory=== |
===apertium-tagger hanging with 100 % cpu, eating memory=== |
||
This can happen if you don't have a UTF-8 locale, reproducible with e.g. |
This can happen if you don't have a UTF-8 locale, reproducible on Arch Linux with e.g. |
||
<pre> |
<pre> |
||
echo '^cows/cow<n><pl>/cow<vblex><pres>$ ^have/have<vbhaver><pres>$' |LC_ALL=C apertium-tagger -g eng-sco.prob |
echo '^cows/cow<n><pl>/cow<vblex><pres>$ ^have/have<vbhaver><pres>$' |LC_ALL=C apertium-tagger -g eng-sco.prob |
Revision as of 11:47, 10 April 2015
Errors which may be encountered during installation and their solutions.
Configure / autogen.sh errors
../ltmain.sh not found
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 && svn co …)
No package lttoolbox/apertium found
When running configure script for Apertium
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.
When running configure script for language pair data
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
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)
AP_CHECK_LING not found when running configure or autogen.sh
./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 svn up
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
Many Apertium pairs (Welsh, Breton, Norwegian, Sámi, …) now require the Constraint Grammar package to help with disambiguation. For install instructions go here.
PCRE
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
- 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.
First off, make sure you've run ./autogen.sh in both the monolingual packages and the language pair. This typically fixes it.
If not, 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
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
crtn.o: No such file or directory
.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
possible solution: use "make" instead of "make -j3"
Command not found
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):
$ 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.
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, runldconfig
- If it isn't, either add
/usr/local/lib
to/etc/ld.so.conf
and re-runldconfig
, or do step 1.
- Check to see if
Error in pcre_compile
- 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""
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.
In Ubuntu at least, you can try something like
locale-gen es_EN.UTF-8
//replace es_EN.UTF-8 with whichever locale you should have installed
For example, if
LANG=es_ES.utf8 /usr/local/bin/apertium-deshtml /tmp/URLMH0f38
gave you the error : 'Warning: unsupported locale, fallback to "C"'. Then you could try
locale-gen es_EN.UTF-8
also see this link for an alternate method : http://tlug.dnho.net/node/237
‘rpl_malloc’ was not declared in this scope
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
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 .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
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
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
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
Runtime errors
Error: Unknown error matching regexp (code -16)
- 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
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.
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")
Missing pair
$ 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
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.