I am trying to cross compile Pocketsphinx for ARM processor (Beagleboard). I
get the following error.
/usr/lib/libasound.so: could not read symbols: File in wrong format.
./configure is able to detect alsa headers as shown by the following output checking alsa/asoundlib.h usability... yes
checking alsa/asoundlib.h presence... yes
checking for alsa/asoundlib.h... yes
checking for snd_pcm_open in -lasound... yes
However while compiling the toolchain is looking for the alsa libraries in
/usr/lib which contains the libraries for the host machine (x86). The
libraries for the target machine (arm9) are kept in the /toolchain/lib folder.
Where do I give the correct path for the correct lib. Does the path need to be
specified while executing the ./configure command. I have executed the
configure with the following command line ./configure --host-arm-none-linux-gnueabi --enable-fixed --without-lapack --enable-fixed16 --without-python
With regards
Pankaj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The question is on what stage it breaks. If configure checks the proper
library in /toolchain/lib or the default library in /usr/lib. You can find
details in config.log. You need to find out which library is picked during
configure check. If it's wrong library, you need to adjust configure behavior
with LDFLAGS=... ./configure if not then the question is why make didn't pick
proper library as configure.
In any case it's better to provide both config.log where configure checks are
stored and full build log.
I had a similar problem, i was trying to cross-compile for the OMAP3530 (on
the Mistral EVM).
What happens is the following: When the script (configure.sh) searches for the
files needed for compilation is searches in the default system path
(/usr/include /usr/lib) and that`s why it shows you that it finds the files
and the libraries for ALSA, but those libraries are compiled to run on an x86
or x64 machine and not on an ARM architecture.
What you need to do is to is either cross compile the ALSA lib using the ARM
toolchain or download the latest TI OMAP35x DVSDK and follow the instructions
to install it. Inside the installed folders from the DVSDK you will find that
the ALSA libraries are allready compiled and all you have to do is to pass the
the configure.sh script the proper parameters, in order for compilation to
work as expected (that means you have to tell the script to search for the
source files and the libraries inside the DVSDK folders).
I don't have the configuration command i used at hand right now, but if you
think it might help you i can look it up and post it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would appreciate if you can look up the configuration command and post it.
Right now for compilation purpose I am replacing the system alsa libraries by
the cross compiled libraries. I want to follow a clean method.
Pankaj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So after i downloaded the TI OMAP35x DVSDK i rebuilt everything (including the
ALSA libraries) using the makefile that comes with the SDK. (i presume you
have an arm toolchain installed i use CodeSourcery's arm2009 compiler)
After which i searched and found where the newly compiled libraries are stored
and passed them to the script
This worked for me..of course you have the change the paths accordingly to
your own paths. Pay attention to the paths where you install the sphinxbase
files. I recommend changing(as i did) the target location of sphinxbase
libraries(using the --prefix and --exec-prefix commands see ./configure -help
for more info) because you will need to copy them onto the board and this way
they will not get mixed up with your computer's libraries ). Furthermore the
last CFLAGS are not mandatory, execept the -lasound one (which tells the
compiler what is the name of the library where the ALSA functions are found).
Not including this will cause some other errors.
Hope this helps you. If you have other questions i will try to help you. Also
if you manage to compile everything and use the program on the board i would
be interested in how it works for you (i have some problems when using the
pocketsphinx_continuous program).
A good day,
Florin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think i compiled the way you did and just used OSS libraries.
config.log provides additional information about the checks performed, the
library choosen and the reasons behind that. If it picked OSS it means that it
failed to find alsa.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to cross compile Pocketsphinx for ARM processor (Beagleboard). I
get the following error.
/usr/lib/libasound.so: could not read symbols: File in wrong format.
./configure is able to detect alsa headers as shown by the following output
checking alsa/asoundlib.h usability... yes
checking alsa/asoundlib.h presence... yes
checking for alsa/asoundlib.h... yes
checking for snd_pcm_open in -lasound... yes
However while compiling the toolchain is looking for the alsa libraries in
/usr/lib which contains the libraries for the host machine (x86). The
libraries for the target machine (arm9) are kept in the /toolchain/lib folder.
Where do I give the correct path for the correct lib. Does the path need to be
specified while executing the ./configure command. I have executed the
configure with the following command line
./configure --host-arm-none-linux-gnueabi --enable-fixed --without-lapack --enable-fixed16 --without-python
With regards
Pankaj
Help please !!!!
Thanks
Pankaj
The question is on what stage it breaks. If configure checks the proper
library in /toolchain/lib or the default library in /usr/lib. You can find
details in config.log. You need to find out which library is picked during
configure check. If it's wrong library, you need to adjust configure behavior
with LDFLAGS=... ./configure if not then the question is why make didn't pick
proper library as configure.
In any case it's better to provide both config.log where configure checks are
stored and full build log.
It might be a libtool issue too. See for example http://metastatic.org/text/l
ibtool.html
See also
https://sourceforge.net/projects/cmusphinx/forums/forum/5471/topic/4611711
Hey pankaj,
I had a similar problem, i was trying to cross-compile for the OMAP3530 (on
the Mistral EVM).
What happens is the following: When the script (configure.sh) searches for the
files needed for compilation is searches in the default system path
(/usr/include /usr/lib) and that`s why it shows you that it finds the files
and the libraries for ALSA, but those libraries are compiled to run on an x86
or x64 machine and not on an ARM architecture.
What you need to do is to is either cross compile the ALSA lib using the ARM
toolchain or download the latest TI OMAP35x DVSDK and follow the instructions
to install it. Inside the installed folders from the DVSDK you will find that
the ALSA libraries are allready compiled and all you have to do is to pass the
the configure.sh script the proper parameters, in order for compilation to
work as expected (that means you have to tell the script to search for the
source files and the libraries inside the DVSDK folders).
I don't have the configuration command i used at hand right now, but if you
think it might help you i can look it up and post it.
Hi Pitt,
I would appreciate if you can look up the configuration command and post it.
Right now for compilation purpose I am replacing the system alsa libraries by
the cross compiled libraries. I want to follow a clean method.
Pankaj
Hey pankaj,
So after i downloaded the TI OMAP35x DVSDK i rebuilt everything (including the
ALSA libraries) using the makefile that comes with the SDK. (i presume you
have an arm toolchain installed i use CodeSourcery's arm2009 compiler)
After which i searched and found where the newly compiled libraries are stored
and passed them to the script
./configure CC=arm-none-linux-gnueabi-gcc CPP=arm-none-linux-gnueabi-cpp
--host=arm-none-linux-gnueabi
LDFLAGS="-L/home/florin/Desktop/sphinxARM/ARM/lib/ -L/home/florin/ti-
dvsdk_omap3530-evm_4_01_00_09/linux-devkit/arm-none-linux-gnueabi/usr/lib"
CPPFLAGS="-I/home/florin/ti-dvsdk_omap3530-evm_4_01_00_09/linux-devkit/arm-
none-linux-gnueabi/usr/include/ -I/home/florin/ti-
dvsdk_omap3530-evm_4_01_00_09/linux-devkit/arm-none-linux-
gnueabi/usr/include/alsa/" --program-suffix=ARM
--prefix=/home/florin/Desktop/sphinxARM/Indep/ --exec-
prefix=/home/florin/Desktop/sphinxARM/ARM/ CFLAGS="-O3 -mcpu=cortex-a8
-mfpu=neon -ftree-vectorize -ffast-math -fsingle-precision-constant -lasound"
This worked for me..of course you have the change the paths accordingly to
your own paths. Pay attention to the paths where you install the sphinxbase
files. I recommend changing(as i did) the target location of sphinxbase
libraries(using the --prefix and --exec-prefix commands see ./configure -help
for more info) because you will need to copy them onto the board and this way
they will not get mixed up with your computer's libraries ). Furthermore the
last CFLAGS are not mandatory, execept the -lasound one (which tells the
compiler what is the name of the library where the ALSA functions are found).
Not including this will cause some other errors.
Hope this helps you. If you have other questions i will try to help you. Also
if you manage to compile everything and use the program on the board i would
be interested in how it works for you (i have some problems when using the
pocketsphinx_continuous program).
A good day,
Florin
i my case, i also successful configure for beagleboard with two options:
./configure --build=i686 --host=arm-linux
--build=i686 for architect of building computer
--host=arm-linux for beagleboar architect
And did it use the ALSA libraries? I think i compiled the way you did and just
used OSS libraries.
config.log provides additional information about the checks performed, the
library choosen and the reasons behind that. If it picked OSS it means that it
failed to find alsa.