1 year, 5 months ago
Dependency issues on an embedded ARM NAS - libdlna can't find libavformat even though it is clearly there.
Very new to linux here.
I'm trying to build libdlna on my NAS with the ultimate goal of getting ushare on there.
Libdlna is dependant on libavformat and something else both of which are in FFmpeg so easy peasy: # apt-get install ffmpeg
so now:
# wget http://libdlna.geexbox.org/releases/libdlna-0.2.3.tar.bz2
# tar -jxvf libdlna-0.2.3.tar.bz2
# cd libdlna-0.2.3
# ./configure
Checking for compiler available...
Checking for libavformat ...
Error, can't find libavformat !
See file "config.log" produced by configure for more details.
Googling reveals that libavformat's 'header' files (don't know what they are) have been moved but libdlna hasn't been updated to look in the new location. Aparently, and I quote 'avformat.h is in /usr/include/libavformat/ and not /usr/include/ffmpeg'
My question is what can I do about this? can I just make a link between the two locations? edit the source code with the new location? Move or copy the library to both locations?
explanation of the commands used in your answers would be helpful.
https://bbs.archlinux.org/viewtopic.php?id=53485 this thread seems to be my problem.
https://bbs.archlinux.org/viewtopic.php?id=52296 Don't know if this is relevant
http://capuzzo.free.fr/beagleboard/dlnasrvr.html This may be what I need to do but I don't know how to adapt the commands to my box and its file system.
Here's the output of config.log:
# ./configure
BASH=/bin/sh
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=(0="0")
BASH_SOURCE=(0="./configure")
BASH_VERSINFO=(0="3" 1="1" 2="17" 3="1" 4="release" 5="arm-unknown-linux-gnu")
BASH_VERSION='3.1.17(1)-release'
CONFIGFILE=config.mak
DIRSTACK=()
EUID=0
GROUPS=()
HOME=/root
HOSTNAME=Server
HOSTTYPE=arm
IFS='
'
INSTALL='/usr/bin/install -c'
LOGNAME=root
MACHTYPE=arm-unknown-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/bin:/usr/sbin:/bin:/sbin
PIPESTATUS=(0="0")
POSIXLY_CORRECT=y
PPID=2684
PREFIX=/usr/local
PS4='+ '
PWD=/libdlna-0.2.3
RANDOM=14485
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=2
TERM=xterm
TMPC=/tmp/libdlna-13422-3448-25802.c
TMPDIR1=/tmp
TMPE=/tmp/libdlna-7720-3448-13521
TMPO=/tmp/libdlna-24958-3448-9362.o
TMPS=/tmp/libdlna-7760-3448-14485.S
UID=0
USER=root
VERSION=
_='# ./configure '
ar=ar
cc=gcc
cpu=armv4l
cross_compile=no
debug=no
dostrip=yes
extralibs=
includedir='$(PREFIX)/include'
installstrip=-s
libdir='$(PREFIX)/lib'
logfile=config.log
logging=yes
make=make
optimize=yes
ranlib=ranlib
shared=yes
static=yes
strip=strip
Checking for compiler available...
check_ld
check_cc
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int main(){
2 return 0;
3 }
END /tmp/libdlna-13422-3448-25802.c
gcc -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
gcc -o /tmp/libdlna-7720-3448-13521 /tmp/libdlna-24958-3448-9362.o
check_header altivec.h
check_cpp
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -E -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
/tmp/libdlna-13422-3448-25802.c:1:21: error: altivec.h: No such file or directory
check_cc -msse
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int main(void) {
3 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)
4 return 0;
5 #else
6 #error no vector builtins
7 #endif
8 }
END /tmp/libdlna-13422-3448-25802.c
gcc -msse -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
cc1: error: unrecognized command line option "-msse"
check_cc -march=athlon
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int main(void) {
3 __m64 b1;
4 b1 = _m_pswapd(b1);
5 _m_femms();
6 return 0;
7 }
END /tmp/libdlna-13422-3448-25802.c
gcc -march=athlon -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
/tmp/libdlna-13422-3448-25802.c:1: error: bad value (athlon) for -march= switch
check_ld
check_cc
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int main(int argc, char ** argv){
3 volatile uint32_t i=0x01234567;
4 return (*((uint8_t*)(&i))) == 0x67;
5 }
END /tmp/libdlna-13422-3448-25802.c
gcc -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
gcc -o /tmp/libdlna-7720-3448-13521 /tmp/libdlna-24958-3448-9362.o
check_cflags -W
check_cc -W
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -Wall
check_cc -Wall
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -D_LARGEFILE_SOURCE
check_cc -D_LARGEFILE_SOURCE
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -D_LARGEFILE_SOURCE -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -D_FILE_OFFSET_BITS=64
check_cc -D_FILE_OFFSET_BITS=64
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -D_REENTRANT
check_cc -D_REENTRANT
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
Checking for libavformat ...
check_lib ffmpeg/avformat.h av_register_all -lavformat
check_header ffmpeg/avformat.h
check_cpp
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
I'm trying to build libdlna on my NAS with the ultimate goal of getting ushare on there.
Libdlna is dependant on libavformat and something else both of which are in FFmpeg so easy peasy: # apt-get install ffmpeg
so now:
# wget http://libdlna.geexbox.org/releases/libdlna-0.2.3.tar.bz2
# tar -jxvf libdlna-0.2.3.tar.bz2
# cd libdlna-0.2.3
# ./configure
Checking for compiler available...
Checking for libavformat ...
Error, can't find libavformat !
See file "config.log" produced by configure for more details.
Googling reveals that libavformat's 'header' files (don't know what they are) have been moved but libdlna hasn't been updated to look in the new location. Aparently, and I quote 'avformat.h is in /usr/include/libavformat/ and not /usr/include/ffmpeg'
My question is what can I do about this? can I just make a link between the two locations? edit the source code with the new location? Move or copy the library to both locations?
explanation of the commands used in your answers would be helpful.
https://bbs.archlinux.org/viewtopic.php?id=53485 this thread seems to be my problem.
https://bbs.archlinux.org/viewtopic.php?id=52296 Don't know if this is relevant
http://capuzzo.free.fr/beagleboard/dlnasrvr.html This may be what I need to do but I don't know how to adapt the commands to my box and its file system.
Here's the output of config.log:
# ./configure
BASH=/bin/sh
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=(0="0")
BASH_SOURCE=(0="./configure")
BASH_VERSINFO=(0="3" 1="1" 2="17" 3="1" 4="release" 5="arm-unknown-linux-gnu")
BASH_VERSION='3.1.17(1)-release'
CONFIGFILE=config.mak
DIRSTACK=()
EUID=0
GROUPS=()
HOME=/root
HOSTNAME=Server
HOSTTYPE=arm
IFS='
'
INSTALL='/usr/bin/install -c'
LOGNAME=root
MACHTYPE=arm-unknown-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/bin:/usr/sbin:/bin:/sbin
PIPESTATUS=(0="0")
POSIXLY_CORRECT=y
PPID=2684
PREFIX=/usr/local
PS4='+ '
PWD=/libdlna-0.2.3
RANDOM=14485
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=2
TERM=xterm
TMPC=/tmp/libdlna-13422-3448-25802.c
TMPDIR1=/tmp
TMPE=/tmp/libdlna-7720-3448-13521
TMPO=/tmp/libdlna-24958-3448-9362.o
TMPS=/tmp/libdlna-7760-3448-14485.S
UID=0
USER=root
VERSION=
_='# ./configure '
ar=ar
cc=gcc
cpu=armv4l
cross_compile=no
debug=no
dostrip=yes
extralibs=
includedir='$(PREFIX)/include'
installstrip=-s
libdir='$(PREFIX)/lib'
logfile=config.log
logging=yes
make=make
optimize=yes
ranlib=ranlib
shared=yes
static=yes
strip=strip
Checking for compiler available...
check_ld
check_cc
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int main(){
2 return 0;
3 }
END /tmp/libdlna-13422-3448-25802.c
gcc -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
gcc -o /tmp/libdlna-7720-3448-13521 /tmp/libdlna-24958-3448-9362.o
check_header altivec.h
check_cpp
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -E -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
/tmp/libdlna-13422-3448-25802.c:1:21: error: altivec.h: No such file or directory
check_cc -msse
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int main(void) {
3 #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)
4 return 0;
5 #else
6 #error no vector builtins
7 #endif
8 }
END /tmp/libdlna-13422-3448-25802.c
gcc -msse -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
cc1: error: unrecognized command line option "-msse"
check_cc -march=athlon
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int main(void) {
3 __m64 b1;
4 b1 = _m_pswapd(b1);
5 _m_femms();
6 return 0;
7 }
END /tmp/libdlna-13422-3448-25802.c
gcc -march=athlon -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
/tmp/libdlna-13422-3448-25802.c:1: error: bad value (athlon) for -march= switch
check_ld
check_cc
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
2 int main(int argc, char ** argv){
3 volatile uint32_t i=0x01234567;
4 return (*((uint8_t*)(&i))) == 0x67;
5 }
END /tmp/libdlna-13422-3448-25802.c
gcc -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
gcc -o /tmp/libdlna-7720-3448-13521 /tmp/libdlna-24958-3448-9362.o
check_cflags -W
check_cc -W
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -Wall
check_cc -Wall
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -D_LARGEFILE_SOURCE
check_cc -D_LARGEFILE_SOURCE
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -D_LARGEFILE_SOURCE -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -D_FILE_OFFSET_BITS=64
check_cc -D_FILE_OFFSET_BITS=64
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
check_cflags -D_REENTRANT
check_cc -D_REENTRANT
BEGIN /tmp/libdlna-13422-3448-25802.c
1 int x;
END /tmp/libdlna-13422-3448-25802.c
gcc -W -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -o /tmp/libdlna-24958-3448-9362.o /tmp/libdlna-13422-3448-25802.c
Checking for libavformat ...
check_lib ffmpeg/avformat.h av_register_all -lavformat
check_header ffmpeg/avformat.h
check_cpp
BEGIN /tmp/libdlna-13422-3448-25802.c
1 #include
You can leave an optional "tip" with Mahalo's virtual currency, Mahalo Dollars. If you are asking a difficult question that might require some research, or if you'd like a wide variety of feedback, a higher tip often leads to more answers to your question.
M$1 Answer
Wow, this is probably way beyond most people's hacking abilities here. And you are stretching mine. But let's start the banter and see if we can't get closer to an answer:
Most programming languages try to simplify things by grouping like items together. Sometimes is works (C) and sometimes it gets out of hand (Cobal). A header file (in most languages) groups the descriptions of variables, functions and constants together. You are essentially telling everyone (compiler included) how you intend to use these things. This is especially important when writing bits and pieces of code you intend for others to use in their programs. That is, when you write a LIBRARY of programs.
Many many other programs will use common library files. The thought; this will cut down on the average program size. The problem; keeping everyone up to date on how to interface with the library and (as you have found out) where that library is.
So, if you suffer a "disconnect" - that is to say your program can not find a library and you have verified that library is available to it - you might consider either your program or your library is not up-to-date. That they might be incompatible. Usually programmers either say what version of a library their programs will work with or their programs check for them selves. If not, you might google around for an answer.
But, as it sounds like in this case, you believe your program and libraries are compatible, you can go about fixing the problem in a number of ways. You can try, as you said, a link (go to where you want the header file to appear and "ln -s path_to_current_header_file_location"). You can copy the header file to the new location. You can try to set an environmental variable to search for the header file in it's current location. You can try and see if there was an option you could have set to tell your program where the libraries were back when you compiled it.
That last one can be tricky to explain. It really depends on if the program's author created all the necessary compiler scripts so that people could build his/her program locally. And, to add confusion, there are several commonly accepted ways of doing this. All of which could stretch this explanation a great deal.
The second to the last is also tricky to explain. How you do it depends on several things (the shell you are running in and if the programs looks for and accept the convention that such a variable will have a default name like LIBRARYPATH).
Also consider that there may be dozen of header files and that they are, as far as your program is concerned, all in the wrong place. If this is the case, I would try setting the LIBRARYPATH to see if it fixes the problem. If you want to go about this a bit more rigorously, check your program to see if how it is finding it's libraries. Sometimes this is set up in the make file so when you compile your program the path is embedded. That is, if you are using a make file to control the compiling of your program.
In the end, there is always more then one way to do this. Start with the obvious (is everything up to date or at least compatible?). Then try to figure out a global solution (compiler time setting or environmental variables). Finally resort to brute force solutions like moving, copying or linking files.
Also remember you are working on a small embedded system which you will undoubtedly reboot often. So, keep in mind if you go setting variables up - they might not survive a reboot - that you will need to set up some sort of script that re-sets these variable before running your program. Most people call this a wrapper and set the variables in the wrapper script/program which then calls the real program which should inherit the variables.
-good luck
Most programming languages try to simplify things by grouping like items together. Sometimes is works (C) and sometimes it gets out of hand (Cobal). A header file (in most languages) groups the descriptions of variables, functions and constants together. You are essentially telling everyone (compiler included) how you intend to use these things. This is especially important when writing bits and pieces of code you intend for others to use in their programs. That is, when you write a LIBRARY of programs.
Many many other programs will use common library files. The thought; this will cut down on the average program size. The problem; keeping everyone up to date on how to interface with the library and (as you have found out) where that library is.
So, if you suffer a "disconnect" - that is to say your program can not find a library and you have verified that library is available to it - you might consider either your program or your library is not up-to-date. That they might be incompatible. Usually programmers either say what version of a library their programs will work with or their programs check for them selves. If not, you might google around for an answer.
But, as it sounds like in this case, you believe your program and libraries are compatible, you can go about fixing the problem in a number of ways. You can try, as you said, a link (go to where you want the header file to appear and "ln -s path_to_current_header_file_location"). You can copy the header file to the new location. You can try to set an environmental variable to search for the header file in it's current location. You can try and see if there was an option you could have set to tell your program where the libraries were back when you compiled it.
That last one can be tricky to explain. It really depends on if the program's author created all the necessary compiler scripts so that people could build his/her program locally. And, to add confusion, there are several commonly accepted ways of doing this. All of which could stretch this explanation a great deal.
The second to the last is also tricky to explain. How you do it depends on several things (the shell you are running in and if the programs looks for and accept the convention that such a variable will have a default name like LIBRARYPATH).
Also consider that there may be dozen of header files and that they are, as far as your program is concerned, all in the wrong place. If this is the case, I would try setting the LIBRARYPATH to see if it fixes the problem. If you want to go about this a bit more rigorously, check your program to see if how it is finding it's libraries. Sometimes this is set up in the make file so when you compile your program the path is embedded. That is, if you are using a make file to control the compiling of your program.
In the end, there is always more then one way to do this. Start with the obvious (is everything up to date or at least compatible?). Then try to figure out a global solution (compiler time setting or environmental variables). Finally resort to brute force solutions like moving, copying or linking files.
Also remember you are working on a small embedded system which you will undoubtedly reboot often. So, keep in mind if you go setting variables up - they might not survive a reboot - that you will need to set up some sort of script that re-sets these variable before running your program. Most people call this a wrapper and set the variables in the wrapper script/program which then calls the real program which should inherit the variables.
-good luck
You can leave an optional "tip" with Mahalo's virtual currency, Mahalo Dollars. If you are asking a difficult question that might require some research, or if you'd like a wide variety of feedback, a higher tip often leads to more answers to your question.
M$
Thanks