I tried to install OpenFst to use it with SphinxTrain and recompile it with g2p enabled, and it seem to work but I got stuck with the following error :
checking fst/fstlib.h usability...
no checking fst/fstlib.h presence...
no checking for fst/fstlib.h...
no configure: error: fst/fstlib.h header not found
But the OpenFst binaries are well installed in /usr/local/lib/fst and the headers too in /usr/local/include/fst..
Can anyone give me a clue about the issue ?
Answer copied from https://sourceforge.net/p/cmusphinx/discussion/help/thread/c58f60cb/:
It looks in /usr/include by default, not in /usr/local/include. You probably need to set CFLAGS and LDFLAGS before configure:
CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure ....
Overall I do not recommend you to use this feature, it never worked well. Use phonetisaurus to extend the dictionary or g2p-seq2seq.
Related
First of all, I'm aware of this answer, yet as it's quite vague, it didn't help me solve my problem.
I'm working on CentOS machine and as current subversion package is quite old, I needed to compile svn by myself. I've managed to do that, but trying to use one of commands I need, which is:
$ svnsync initialize [...] [...]
Resulted with the following error:
svnsync: E170000: Unrecognized URL scheme for '[url here]'
After some research, I found that I need serf to make it work, so I've installed it by using yum install libserf (I'm not sure if it's it, but name and description sound similar to what I need). Unfortunately, nothing has changed and I later came to a conclusion that maybe I need to recompile svn with serf in place.
I've downloaded subversion source and ran ./configure. Here is the output of it associated with serf:
configure: serf library configuration via pkg-config
checking for serf-2 library... no
checking for serf-1 library... no
checking was serf enabled... no
An appropriate version of serf could not be found, so libsvn_ra_serf
will not be built. If you want to build libsvn_ra_serf, please
install serf 1.3.4 or newer.
There is an argument called --with-serf, but I'm not sure how should I use it. Linking to location of serf binaries, like that:
$ ./configure --with-serf=/usr/lib64/
results with the following output:
configure: serf library configuration via pkg-config
checking for serf-2 library... no
checking for serf-1 library... no
checking was serf enabled... no
An appropriate version of serf could not be found, so libsvn_ra_serf
will not be built. If you want to build libsvn_ra_serf, please
install serf 1.3.4 or newer.
configure: error: Serf was explicitly enabled but an appropriate version was not found.
Can you give me some hints on how can I proceed with this?
I'm using ubuntu 14.04 and i'm trying to install the UHD device from the github but i'm getting an error that won't allow it to build.
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
willie.thompson#seb215-wks07:~/redhawk/USRP_UHD/cpp$ make
CXX USRP_UHD-USRP_UHD.o
CXX USRP_UHD-USRP_UHD_base.o
CXX USRP_UHD-main.o
CXX USRP_UHD-template_impl.o
CXXLD USRP_UHD
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
seb215-wks07:~/redhawk/USRP_UHD/cpp$
Am I doing something wrong here or is the issue with Ubuntu?
For now, you can edit the Makefile.am file to fix this. At the end of the USRP_UHD_LDADD line, add -luuid, then you should be able to rebuild it successfully.
The version of g++ used in Ubuntu14 is stricter than the version used in CentOS6. Luckily, g++ is providing a good hint about what the issue is.
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
It is basically saying "What you want is here in libuuid.so.1 but you didn't put it on the command line so I'm refusing to use it". While in CentOS6 g++ is less strict and links regardless, assuming that is what you wanted.
You have two options, one is the easy way out that works quick, one is a better long term solution:
1) Run make again in verbose mode, this will show you exactly what calls are being made and you can fix the offending call. Lets do that below:
make V=1
< ... a bunch of calls to g++ that work fine or nothing if these have already run prior .... >
g++ -Wall -D__x86_64__ -D__linux__ -D__OSVERSION__=2 -DENABLE_EVENTS=1 -I/var/lib/redhawk/core/include -I/var/lib/redhawk/core/include/ossie -I/var/lib/redhawk/core/share/idl -pthread -I/usr/include -I/var/lib/redhawk/core/include/frontend -I/var/lib/redhawk/core/include/redhawk -I/var/lib/redhawk/core/include/bulkio -I/var/lib/redhawk/core/include/ossie -g -O2 -Wall -o USRP_UHD USRP_UHD-USRP_UHD.o USRP_UHD-USRP_UHD_base.o USRP_UHD-main.o USRP_UHD-template_impl.o -L/var/lib/redhawk/core/lib64 -lossiecf -lossieidl -lCOS4 -lomniDynamic4 -lomniORB4 -lomnithread -L/usr/lib/x86_64-linux-gnu -lboost_thread -lboost_regex -lboost_system -L/var/lib/redhawk/core/lib64 -lfrontend-2.2.0 -lfrontendInterfaces -lbulkio-1.10 -lbulkioInterfaces -luhd -llog4cxx
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
Okay, so now we have the long ugly g++ call, we simply need to add "-luuid" to the list of linked libraries so we can tack that on at the end and voila! It will return without error. Note that we simply hand ran 1 of the g++ calls so for good measure run Make again in case there are any additional build steps; in this case there are not, it will simply say "nothing to be done"
2) A better fix! So the build files clearly need some fixing.
If we take a look at the configure.ac we see that there are calls like this one:
PKG_CHECK_MODULES([LIBUHD], [uhd >= 3.5.3])
What this is doing is saying "Check pkg-config for the module uhd, ensure it is of version >= 3.5.3 and store any build related info in a variables prefixed with LIBUHD so that I can use it later". Sounds like what we want. We can check to see if pkg-config is aware of libuuid by viewing all of the packages it knows about:
pkg-config --list-all
That will show us everything pkg-config knows about and we see that it is aware of uuid. So, lets add a line to configure.ac right below the check for the UHD driver and see what affect that has. My line looks like this:
PKG_CHECK_MODULES([LIBUUID], [uuid])
I put no version constraint. Okay, so now in order for that change to be incorporated we need to rerun the reconf script and then we can see the configure output.
./reconf
./configure
<....a bunch of stuff....>
checking for LIBUUID... yes
<....a bunch more stuff....>
That's new! We are now checking for the uuid library in our configure call and if you take a look at the config.log file, new variables have been added:
LIBUUID_CFLAGS='-I/usr/include/uuid '
LIBUUID_LIBS='-luuid '
Alright, almost there! Take a look at the Makefile.am file. These variables are used there and dictate the calls to g++. Append our newly made LIBUUID_CFLAGS and LIBUUID_LIBS variables to the end of the USRP_UHD_LDADD and USRP_UHD_CXXFLAGS variables like I've done below.
USRP_UHD_LDADD = $(PROJECTDEPS_LIBS) $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB) $(BOOST_REGEX_LIB) $(BOOST_SYSTEM_LIB) $(INTERFACEDEPS_LIBS) $(redhawk_LDADD_auto) $(LIBUHD_LIBS) $(LIBUUID_LIBS)
USRP_UHD_CXXFLAGS = -Wall $(PROJECTDEPS_CFLAGS) $(BOOST_CPPFLAGS) $(INTERFACEDEPS_CFLAGS) $(redhawk_INCLUDES_auto) $(LIBUHD_FLAGS) $(LIBUUID_CFLAGS)
Since we've changed the Makefile.am files, we need to rerun ./configure. Rule of thumb is that ./reconf creates your configure script from the configure.* files and ./configure creates the Makefile's from your Makefile.* files so if you edit a downstream file you need to rerun the upstream script.
Alright, now that we've done that things should work! We've added a system check for libuuid via pkg-config using the configure.ac file, stored the outcome in a variable and used that in our makefile template.
None of this is really unique to redhawk so if you'd like more information there is loads of documentation on the autotools build system and pkg-config.
./configure --user=boxflux
--group=boxflux
--prefix=/usr/local/nginx-1.3.0
--with-pcre=/usr/lib64
--with-md5=/usr/lib64
--with-sha1=/usr/lib64
--with-zlib=/usr/lib64
--with-libatomic=/usr/lib64
--with-openssl=/usr/lib64 | grep 'not found'
checking for sys/filio.h ... not found
checking for /dev/poll ... not found
checking for kqueue ... not found
checking for crypt() ... not found
checking for F_READAHEAD ... not found
checking for F_NOCACHE ... not found
checking for directio() ... not found
checking for dlopen() ... not found
checking for SO_SETFIB ... not found
checking for SO_ACCEPTFILTER ... not found
checking for setproctitle() ... not found
checking for POSIX semaphores ... not found
checking for struct dirent.d_namlen ... not found
I have a problem installing nginx..
I've already installed gcc, pcre*, zlib*, openssl* by using 'yum'
What's problem with my configuration?
By the way, my computer is 64bit centos6 and I'm now installing nginx 1.3.0 (development version)
--------- ADDITOIN -----------------------
I forgot to mention that it was even worse than I added those --with-*=DIR...
When I run a line of code kolbyjack gave me, the result is..
./configure --user=boxflux --group=boxflux --prefix=/usr/local/nginx-1.3.0 |grep 'not found'
checking for sys/filio.h ... not found
checking for /dev/poll ... not found
checking for kqueue ... not found
checking for crypt() ... not found
checking for F_READAHEAD ... not found
checking for F_NOCACHE ... not found
checking for directio() ... not found
checking for dlopen() ... not found
checking for SO_SETFIB ... not found
checking for SO_ACCEPTFILTER ... not found
checking for setproctitle() ... not found
checking for POSIX semaphores ... not found
checking for struct dirent.d_namlen ... not found
checking for PCRE JIT support ... not found
checking for system md library ... not found
checking for system md5 library ... not found
checking for sha1 in system md library ... not found
Since I am a newbie on centos6.. I really have no any idea on this issue..
please help me..
Often times, I'd prefer not to use "after market" builds from src but instead use the native
CentOS packages.
The "PCRE Library Not Found" error can also be caused when the pcre package is installed but not the pcre-devel package.
Merely, 'yum install pcre-devel' and rerun ./configure.
From ./configure --help:
--with-pcre=DIR set path to PCRE library sources
--with-md5=DIR set path to md5 library sources
--with-sha1=DIR set path to sha1 library sources
--with-zlib=DIR set path to zlib library sources
--with-libatomic=DIR set path to libatomic_ops library sources
--with-openssl=DIR set path to OpenSSL library sources
If you read the help text, each of those options set the directory for the library sources, not the installed version of the library. If the library is already installed on the system, nginx should automatically find it during configure. If it's installed in a nonstandard location, you should use --with-cc-opt and --with-ld-opt to set the include and library paths for nginx to search. Since you've installed all the libs via yum, I expect that all you really need is:
./configure --user=boxflux --group=boxflux --prefix=/usr/local/nginx-1.3.0
I am making a project that uses Autoconf. I have the following in configure.ac:
AC_CHECK_HEADERS([boost/foreach.hpp], [],
[AC_MSG_ERROR(You need the Boost libraries.)])
When I run configure, it says it cannot find this header file:
checking boost/foreach.hpp usability... no
checking boost/foreach.hpp presence... no
checking for boost/foreach.hpp... no
configure: error: You need the Boost libraries.
This is strange, because I have Boost. If I remove the check, the code compiles, and I have Boost installed:
$ find /usr/include -name foreach.hpp
/usr/include/boost/foreach.hpp
/usr/include/boost/test/utils/foreach.hpp
Note that I did exactly the same with SDL, and it works.
AC_CHECK_HEADERS([SDL/SDL.h], [],
[AC_MSG_ERROR(You need the SDL development library.)])
...
checking SDL/SDL.h usability... yes
checking SDL/SDL.h presence... yes
checking for SDL/SDL.h... yes
AC_CHECK_HEADERS actually does a a compile check, not an existence check. So you have to set C++ support for compilation tests in order for boost headers to compile (default is C, docs here):
AC_LANG_PUSH([C++])
AC_CHECK_HEADERS([boost/foreach.hpp], [],
[AC_MSG_ERROR(You need the Boost libraries.)])
AC_LANG_POP([C++])
There's also a collection of Boost autoconf macros at the GNU Autoconf Archive. You'll probably need at least AX_BOOST_BASE. Other macros for the other Boost libs are there also.
You may be interested in github.com/tsuna/boost.m4, which is a drop-in set of Autoconf macros for checking for Boost headers and libraries, as well as the minimum Boost version.
I download the rss-glx 0.9 project's source codes to build. But the configure script complained GL library was not found!
...
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking GL/glx.h usability... yes
checking GL/glx.h presence... yes
checking for GL/glx.h... yes
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: GL library was not found.
But there are GL libraries in /usr/lib.
$ ls /usr/lib/GL*
/usr/lib/libGLcore.so.1 /usr/lib/libGL.so.180.29
/usr/lib/libGLcore.so.180.29 /usr/lib/libGLU.a
/usr/lib/libGLEW.so.1.5 /usr/lib/libGLU.so
/usr/lib/libGLEW.so.1.5.0 /usr/lib/libGLU.so.1
/usr/lib/libGL.la /usr/lib/libGLU.so.1.3.070004
/usr/lib/libGL.so.1
Anybody can tell me why?
Thanks.
Thank you, drhirsch. I have found out the reason. In my /usr/lib, libGL.so is a symbolic link to /usr/lib/nvidia/libGL.so.1.2.xlibmesa. And in /usr/lib/nvidia, there is not a libGL.so.1.2.xlibmesa but a libGL.so.xlibmesa, which is also a symbolic link to a no-existed libGL.so.1. Now I have fixed the problem and it's OK.
I don't know why there are some null symbolic links. I guess it occured when I reinstall the nvidia graphic card driver for my Debian's kernel updated from 2.6.26-1 to 2.6.26-2.
Looks like the linker wasn't able to link a test program against your GL library. (This is was configure does). Possibly a version mismatch.
What exactly has happened is written in the file 'config.log', close to the end, but before the whole envirnoment variables content. You can repeat the last unsuccessful command at the comand line and look a the error the linker throws out.
I had a similar problem once. A quick fix might be to create a symlink called libGL.so and have it point to one of the "other" libGLs
My problem was that the test program couldn't link to libXmu.so, as I found by reading config.log. Turns out on my installation, there was a libXmu.so.6, but no soft link. I did this:
ln -s /usr/lib64/libXmu.so.6 /usr/lib64/libXmu.so
and then the ./configure worked.