Difference between revisions of "Installation troubleshooting"

Revision as of 11:36, 17 March 2015

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.

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.

Shared libraries

lt-comp: error while loading shared libraries:
liblttoolbox3-3.0.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 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
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

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.

Typical solution

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`

There is a patch to apertium (used in the apt repo) that fixes the #Error:_Unknown_error_matching_regexp_.28code_-16.29. 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