Now I want to build the same application for beagleboard target
I have an exact copy of SD card beagleboard rootfs located at /home/
jan/openCV/BB_rootfs/
to crosscompile I do the following sequence:
cd /home/jan/openCV/BB_sources/
export PATH=$PATH:/home/jan/oe/tmp/cross/armv7a/bin/
I am getting an error
/home/jan/oe/tmp/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/
4.3.1/../../../../arm-angstrom-linux-gnueabi/bin/ld: skipping
incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
/home/jan/oe/tmp/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/
4.3.1/../../../../arm-angstrom-linux-gnueabi/bin/ld: cannot find /lib/
libc.so.6
collect2: ld returned 1 exit status
Question:
How to let the compiler know about libc.so.6?
Hello Jan,
I too have just built an openCV app on my Ubuntu workstation and
installed
the svn openCV and recompiled to get my webcam working. This all works
now. Last evening I began trying to accomplish the same on my
BeagleBoard
but could not get openCV to interpret the video from my webcam. Could
not recompile on BB either.
I am very much interested in your progress. I am sorry I dont have
your answer.
--Don
Your problem might be solved using the linker's "-rpath" option. If I
understand this part of "ld" (the linker) correctly, the "-L" option
only specifies directories for static linking, i.e., looking for
"libxxx.a" files. "ld" uses the "-rpath" option to specify a run-time
directory for finding ".so" (shared object) files.
Since gcc/g++ is calling the linker, you have to tell gcc/g++ to pass
the linker option to "ld" using "-Wl" or "-Xlinker". Here's what I do
in my make file:
I will definitely let you know if I have any progress.
My first guess with your problem with camera (which soon might become
my problem, too)
is that opencv library has to be build and configured with codec
support.
read more here http://www.comp.leeds.ac.uk/vision/opencv/install-lin-ffmpeg.html
I will try it.
As we here in Australia have a Queen's Birthday long weeekend I might
be forced to do
some work around house, so will try it later.
The question is how to figure out the name for the library, like it is
-lcv for
libcv, what would be the name for libc.so.6 (c.so.6?) ?
-lxyz tells the linker to look for a file "libxyz.so" in the run-time
directories or "libxyz.a" in the static library directories. So you
would enter "-lc" for "libc.so". In fact, if you're letting gcc or g+
+ call the linker for you, it automatically includes "libc" so you
shouldn't have to enter anything.
I don't know how ld deals with ".so.6", but so far it seems to do the
right thing for me automatically without my specifying ".6" anywhere.
Here's a generic Linux man page for ld: http://linux.die.net/man/1/ld
Take a look at the "-l", "-L", and "-rpath" options.
Another useful trick is to add the "-v" (verbose) option when
compiling. This causes the compiler to list the full commands it uses
for each step in gory detail so you can see which libraries it's
including and where it's looking for them.
/home/jan/oe/tmp/cross/armv7a/lib/gcc/arm-angstrom-linux-gnueabi/
4.3.1/../../../../arm-angstrom-linux-gnueabi/bin/ld: /home/jan/openCV/
BB_rootfs/lib/: No such file: File format not recognized
collect2: ld returned 1 exit status
make: *** [hello-world] Error 1
jan@linuxbox:~/openCV/BB_sources$
Any idea about the error in 4th line from the end?
Thanks again for your time and patience.
Regards
Jan
According to the gcc man page http://linux.die.net/man/1/gcc, "-L"
only specifies a single library directory. The lines:
append $(RTdir) to LIBPATH, but since -L only takes a single directory
as an argument, $(RTdir) is passed as a object file argument to "ld"
which doesn't know what to do with it since it only expects ".o",
".a", and ".so" object and archive files. Try replacing the second
line with:
LIBPATH += -L$(RTdir)
I found this by looking at the arguments of the "collect2" program. I
noticed that $(RTdir) appears twice, once after "-rpath" (which is
correct) and once before "-lcv" (which caused "ld" to fail since it
was not prefixed with "-L").
Yesterday I put a copy of the latest openCV svn on my BB, installed
several
dependencies and built openCV. By doing so I was able to get FFmpeg
and
libv4l2 to work within openCV. Took about 15 minutes to build.
Now openCV supports my webcam, Logitech Chat, on BB. apps compile.
Thank you
Still have no luck, but this time again problem with incompatible
libc.so.6
(There is a file "libc.so.6" located at /home/jan/openCV/BB_rootfs/
lib/)
As my area of expertise is small embedded systems, something between
MSP430 and STM32
and my knowledge of Linux and GNU tools is rather basic I want to
concentrate on
development of applications rather than customizing embedded Linux OS
etc.
Again, much appreciate your help.
I will study the manuals for GNU tools to see if it will help.
Great news, congratulations.
I have no progress at all so far.
I want to have my webcam (Logitech Pro 9000) to be supported by openCv
and be able to create openCv applications, too.
Are you willing to share you knowledge and experience?
Have you used bitbake and OE to build your version of openCV or the
local makefile?
Good day Jan,
I used the latest opencv from their svn download.
I first built it on a linux x86 system and got it working.
Then I copied the source over to Beagle and began.
Building locally on Beagle was time consuming getting all the depend's
together. There were issues with bad paths for FFMPEG files.
If you want I can organize my notes and send you what I have.
My Angstrom build already had mplayer and ffmpeg working with
my webcam so it was not too bad.
Your webcam sounds like a UVC model? I would have thought it
would just work out of the box with Angstrom 2.6.28 or later.
I had to launch opencv with a LD(something) to /usr/local/lib
path. I need to get to my crashed hd and get the specifics. My
Linux Dev station crashed yesterday.
I'm also someone who just wants to use Linux to develop applications.
The idea of recompiling a Linux kernel is to me about as appealing as
recompiling Windows. I also think that turning on the "-v" option
results in output that looks more or less like serial line noise.
There can be useful information in there, but it's challenging cutting
through the noise. GCC has thousands of options and getting the few
you need to the correct values can be very nasty.
I think your problem of an incompatible "libc.so.6" probably has to do
with the (E)ABI (Embedded) Application Binary Interface. The ABI
defines how registers are used for C function calls and other data
structure conventions. Unfortunately, there are a whole bunch of
different ARM ABIs around and your application program must use the
same ABI as your .so files. It sounds like "ld" is nice enough to
check that the .so is compatible, but is unable to find a .so that it
likes.
Hard-core (hard-kernel?) Linux developers don't see this as a problem
since they just go ahead and recompile everything with the same
architectural options so the ABIs match. In my own case I probably
just got lucky and the default configuration of CodeSourcery GNU/Linux
for Windows 2007q3-51 I use happens to match the version of Ångström I
use.
In my own makefile I don't specify a linker -rpath for libc.so, so the
linker finds the libc.so that is included with CodeSourcery and it's
compatible. It also happens to be compatible with Ångström's libc.so
for the version of Ångström I use.
One difference I did notice is that your call to the assembler ".../
as" has argument "-meabi=4" whereas mine has argument "-meabi=5". I
don't know if this makes any difference. The only reference to "-
meabi" I can find in my version of the GCC documentation is for
PowerPC architecture.
I don't know what to recommend at this point. I've had luck with the
2007q3-51 version of CodeSourcery GNU/Linux for developing my own
applications. It seems to have set the options correctly for ARM so
all I have to do is specify "-march=armv7-a" and "-mfloat-abi=softfp"
and I'm good to go.
Thank you again.
On a positive note, I was able to create a working makefile,
successfully build on PC and run on beagleboard
a number of simple opencv applications.
I did apply the commonsense, experimentation and contradicting the
official codesourcery documentation
(it is probably outdated)
No luck so far with camera on opencv, but maybe one day.
Hi Jan,
I emailed you an attachment describing my successful build of
openCV on the BeagleBoard. I hope it helps. Meantime have you
tried to open your camera with a library argument?
Thanks for that and your email, too.
As I have other urgent assignments I have to try it later.
I was hoping that the guys from HBRC http://www.hbrobotics.org/wiki/index.php5/Beagle_Board
will help us, but it looks like they lost enthusiasm as I don't see
any updates from them.
Thanks again and stay in touch.
./configure: WARNING: unrecognized options: --with-x
checking build system type... arm-angstrom-linux-gnueabi
checking host system type... arm-angstrom-linux-gnueabi
checking target system type... arm-angstrom-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for style of include used by make... GNU
checking for arm-angstrom-linux-gnueabi-g++... arm-angstrom-linux-
gnueabi-g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether arm-angstrom-linux-gnueabi-g++ accepts -g... yes
checking dependency style of arm-angstrom-linux-gnueabi-g++... gcc3
checking how to run the C++ preprocessor... arm-angstrom-linux-gnueabi-
g++ -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether arm-angstrom-linux-gnueabi-g++ accepts -g... (cached)
yes
checking dependency style of arm-angstrom-linux-gnueabi-g++...
(cached) gcc3
checking for arm-angstrom-linux-gnueabi-gcc... arm-angstrom-linux-
gnueabi-gcc
checking whether we are using the GNU C compiler... yes
checking whether arm-angstrom-linux-gnueabi-gcc accepts -g... yes
checking for arm-angstrom-linux-gnueabi-gcc option to accept ISO
C89... none needed
checking dependency style of arm-angstrom-linux-gnueabi-gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by arm-angstrom-linux-gnueabi-gcc... /usr/arm-
angstrom-linux-gnueabi/bin/ld
checking if the linker (/usr/arm-angstrom-linux-gnueabi/bin/ld) is GNU
ld... yes
checking for /usr/arm-angstrom-linux-gnueabi/bin/ld option to reload
object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognize dependent libraries... pass_all
checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-
gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... arm-angstrom-linux-gnueabi-
g++ -E
checking for arm-angstrom-linux-gnueabi-g77... no
checking for arm-angstrom-linux-gnueabi-xlf... no
checking for arm-angstrom-linux-gnueabi-f77... no
checking for arm-angstrom-linux-gnueabi-frt... no
checking for arm-angstrom-linux-gnueabi-pgf77... no
checking for arm-angstrom-linux-gnueabi-cf77... no
checking for arm-angstrom-linux-gnueabi-fort77... no
checking for arm-angstrom-linux-gnueabi-fl32... no
checking for arm-angstrom-linux-gnueabi-af77... no
checking for arm-angstrom-linux-gnueabi-xlf90... no
checking for arm-angstrom-linux-gnueabi-f90... no
checking for arm-angstrom-linux-gnueabi-pgf90... no
checking for arm-angstrom-linux-gnueabi-pghpf... no
checking for arm-angstrom-linux-gnueabi-epcf90... no
checking for arm-angstrom-linux-gnueabi-gfortran... no
checking for arm-angstrom-linux-gnueabi-g95... no
checking for arm-angstrom-linux-gnueabi-xlf95... no
checking for arm-angstrom-linux-gnueabi-f95... no
checking for arm-angstrom-linux-gnueabi-fort... no
checking for arm-angstrom-linux-gnueabi-ifort... no
checking for arm-angstrom-linux-gnueabi-ifc... no
checking for arm-angstrom-linux-gnueabi-efc... no
checking for arm-angstrom-linux-gnueabi-pgf95... no
checking for arm-angstrom-linux-gnueabi-lf95... no
checking for arm-angstrom-linux-gnueabi-ftn... no
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking for pgf77... no
checking for cf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for xlf90... no
checking for f90... no
checking for pgf90... no
checking for pghpf... no
checking for epcf90... no
checking for gfortran... no
checking for g95... no
checking for xlf95... no
checking for f95... no
checking for fort... no
checking for ifort... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for ftn... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 1572864
checking command to parse /usr/bin/nm -B output from arm-angstrom-
linux-gnueabi-gcc object... ok
checking for objdir... .libs
checking for arm-angstrom-linux-gnueabi-ar... arm-angstrom-linux-
gnueabi-ar
checking for arm-angstrom-linux-gnueabi-ranlib... arm-angstrom-linux-
gnueabi-ranlib
checking for arm-angstrom-linux-gnueabi-strip... arm-angstrom-linux-
gnueabi-strip
checking if arm-angstrom-linux-gnueabi-gcc supports -fno-rtti -fno-
exceptions... no
checking for arm-angstrom-linux-gnueabi-gcc option to produce PIC... -
fPIC
checking if arm-angstrom-linux-gnueabi-gcc PIC flag -fPIC works... yes
checking if arm-angstrom-linux-gnueabi-gcc static flag -static
works... yes
checking if arm-angstrom-linux-gnueabi-gcc supports -c -o file.o...
yes
checking whether the arm-angstrom-linux-gnueabi-gcc linker (/usr/arm-
angstrom-linux-gnueabi/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by arm-angstrom-linux-gnueabi-g++... /usr/arm-
angstrom-linux-gnueabi/bin/ld
checking if the linker (/usr/arm-angstrom-linux-gnueabi/bin/ld) is GNU
ld... yes
checking whether the arm-angstrom-linux-gnueabi-g++ linker (/usr/arm-
angstrom-linux-gnueabi/bin/ld) supports shared libraries... yes
checking for arm-angstrom-linux-gnueabi-g++ option to produce PIC... -
fPIC
checking if arm-angstrom-linux-gnueabi-g++ PIC flag -fPIC works... yes
checking if arm-angstrom-linux-gnueabi-g++ static flag -static
works... yes
checking if arm-angstrom-linux-gnueabi-g++ supports -c -o file.o...
yes
checking whether the arm-angstrom-linux-gnueabi-g++ linker (/usr/arm-
angstrom-linux-gnueabi/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
(cached) (cached) checking how to hardcode library paths into
programs... immediate
appending configuration tag "F77" to libtool
checking for arm-angstrom-linux-gnueabi-gcc option to support
OpenMP... unsupported
checking for x86 cpuid output... unknown
checking for x86 cpuid 0x00000001 output... unknown
checking whether mmx is supported...
./configure: line 21664: 0xunknown: value too great for base (error
token is "0xunknown")
root@beagleboard:/home/trunk/opencv#
Do you remember your settings for ./configure?
(I have tried as well --build=arm-linux --host=arm-linux with the same
result
Good question, so let me explain why.
Everyone is different and everyone is doing different things.
I'm trying to concentrate on application development on different
platforms rather that
building tools and operating systems.
In case of beagleboard I use the existing images of Angstrom
distribution and it works in many cases.
I understand that it is still an experimental system, so things might
not work.
OE as I was told and experienced is not for application development,
where you change the code, recompile, test, debug many times.
I managed once to create a console image using bitbake and OE strictly
following the instructions and it took about
two dozens attempts and about 2 weeks in real time.
The reason I want to rebuilt opencv library is that it is my desperate
attempt to make it work with USB camera,
as so far it doesn't work for me using available images, that I have
tried.
Thank you for your work for embedded community.
Regards