Installation troubleshooting

En français

⚠ WARNING ⚠

This page is out of date as a result of the migration to GitHub. Please update this page with new documentation and remove this warning. If you are unsure how to proceed, please contact the GitHub migration team.

Errors which may be encountered during installation and their solutions.

apt-get errors

held back packages

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

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

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

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

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.

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

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

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

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

Shared libraries

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:

1. If you have installed it to some $prefix, do: export LD_LIBRARY_PATH=$prefix/lib
2. If you have installed it in /usr/local
   1. Check to see if /usr/local/lib is in /etc/ld.so.conf, if it is, run ldconfig
   2. 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

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

ISO C++1z does not allow 'register' storage

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

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.

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

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