How to compile OpenCV with ICC? - linux

I am trying to compile OpenCV with icc on Linux, in order to profile the execution with intel tools.
I installed the last version of icc with default options. I tried both "user" (icc is installed in my home) and "sudo" (icc is intalled in /opt) installs. The version of icc is 11.1 20090630
I also thought to source iccvars.sh, adding needed paths to PATH and LD_LIBRARY_PATH
I also tried several versions of OpenCV:
- the main one: pre1.1. configure does not recognize icc at all
- the 'latest_tested_snapshot' and the 'trunk' versions: icc is well recognized by configure (--enable-openmp produce -openmp option, and not -fopenmp)
When I make, everything seems all right until the middle of the compilation. Then come a lot of warnings (maybe a hundred) always about 'operator'. Here an example:
../include/opencv/cxcore.hpp(335): warning #597: "cv::Size_<_Tp>::operator cv::Size_<float>() const [with
_Tp=float]" will not be called for implicit or explicit conversions
operator Size_<float>() const;
^
detected during instantiation of class "cv::Size_<_Tp> [with _Tp=float]" at line 394
And finnally the error:
/bin/bash ../../../libtool --tag=CXX --mode=compile icpc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include/opencv -I. -DCV_NO_BACKWARD_COMPATIBILITY -fPIC -I/usr/include/python2.6 -g -O2 -MT _highgui_la-pyhelpers.lo -MD -MP -MF .deps/_highgui_la-pyhelpers.Tpo -c -o _highgui_la-pyhelpers.lo `test -f 'pyhelpers.cpp' || echo './'`pyhelpers.cpp
_ml.cpp(36134): error: argument of type "uchar={unsigned char} *" is incompatible with parameter of type "int *"
result = (int)(arg1)->get_ord_var_data(arg2,arg3,arg4,arg5,(float const **)arg6,(uchar const **)arg7);
^
_ml.cpp(36134): error: argument of type "const uchar={unsigned char} **" is incompatible with parameter of type "const int **"
result = (int)(arg1)->get_ord_var_data(arg2,arg3,arg4,arg5,(float const **)arg6,(uchar const **)arg7);
^
compilation aborted for _ml.cpp (code 2)
make[4]: *** [_ml_la-_ml.lo] Erreur 1
I anyone succeded to compile OpenCV with icc, let me know!

Ok, I finally compiled OpenCV with ICC. OpenCV is close to Intel, as Intel is highly involved in this project. Since version 1.1, OpenCV is supposed to natively support icc compiler. When you specify CC=icc in configure, there are some subtle changes as the -fopenmp (gcc style) in transformed into -openmp (icc style). However, between the release of OpenCV 1.1 (which is the latest stable) and now, icc has evolved. I think it used to compile with previous version of icc.
It comile with the latest tested version on svn:
https://opencvlibrary.svn.sourceforge.net/svnroot/opencvlibrary/tags/latest_tested_snapshot/opencv/
As the svn evolve, it could change, but at this time (27 august) it works. The warnings are still here (don't be affraid, there are a lot). Here my configure bash line:
./configure --prefix=/home/user/opencv/icc CC=icc CXX=icpc --enable-openmp --disable-apps --disable-optimization --disable-sse
I disabled optimizations and sse instructions, as it generates some conflicts with icc.

Your issue may result from using a different version from ICC used to create that library. You must ask the library provider which version to use.

Related

GCC keeps saying -mfpu=neon is an unrecognoized command

I am compiling code to run on an arm neon and the make files have the following command line included.
-mcpu=cortex-a9 -march=armv7 -mfpu=neon -DARM_NEON
The details of GCC version are as follows:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
However when I try to compile, gcc keeps throwing the following error:
gcc: warning: '-mcpu=' is deprecated; use '-mtune=' or '-march=' instead
gcc: error: unrecognized command line option '-mfpu=neon'
I am pretty sure that the code could be compiled previously. Though a long time ago. Could it be changes in version of GCC? or is it do with 32 bit and 64 bit compilers?
I was trying to cross compile for an arm processor on my intel x86_64 Ubuntu machine. I needed to add the configuration for the host in the makefiles and use arm-linux-gnueabihf-gcc instead of gcc.

How to fix error: bad value (native) for -march= switch and -mtune= switch?

I am compiling the library provided here: http://www.robots.ox.ac.uk/~vgg/software/fastann/, but
bash-3.2$ PREFIX=/usr/local/ cmake . && make
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-Wall -O2 -g3 -msse2 -march=native -fno-exceptions -fno-rtti
--- Prefix = /usr/local/
-- Configuring done
-- Generating done
-- Build files have been written to: /path/to/dir
[ 14%] Building CXX object CMakeFiles/fastann.dir/dist_l2.cpp.o
/path/to/dir/dist_l2.cpp:1: error: bad value (native) for -march= switch
/path/to/dir/dist_l2.cpp:1: error: bad value (native) for -mtune= switch
make[2]: *** [CMakeFiles/fastann.dir/dist_l2.cpp.o] Error 1
make[1]: *** [CMakeFiles/fastann.dir/all] Error 2
make: *** [all] Error 2
bash-3.2$
This is only the first step in the provided instruction, and I don't know where to look next. Can somebody tell me what exactly is this error, and how to fix it?
How to fix error: bad value (native) for -march= switch and -mtune= switch?
The problem is with -march=nartive. According to Ian Lance Taylor on GCC's mailing list (Ian is one of the GCC devs):
The problem is that the driver code is not working, and the bug is
that gcc doesn't handle that [-march=native] correctly. There is some code in gcc to
handle the driver code failing, and it works for -mtune=native, but
not for -march=native.
The driver code is supposed to change the -march=native to be
-march=XXX for your CPU. The code is in
gcc/config/i386/driver-i386.c.
So the workaround is to avoid using -march=native; and use either (1) -m32 or -m64, or (2) use -march=cpu-type, where cpu-type is one of the ones listed at 3.17.15 Intel 386 and AMD x86-64 Options of the GCC manual. The list is extensive, and it includes pentium, pentium2, pentium3 and pentium4.
Switch to using a version of gcc equal or larger then 4.2.
gcc's version 4.2 introduced the native march.
Use
gcc --version
to get gcc's version information.

Unresolved sincos during build of LAPACK

Following the instructions here I have built a Fortran enabled NDK toolchain (OSX, NDK-7b) with the goal of building LAPACK/BLAS.
Using android-cmake with the 3.4.0 net lib source it seems that I'm nearly successful. However, the BLAS build fails when linking one of the tests (with an error stating unresolved sincos and sincosf). A little searching reveals that these functions are not available in legacy Android versions. I'm wondering what is the best way to resolve these functions?
Below is and example of a linking error:
cd /Users/marc/software/lapack-3.4.0/Android/BLAS/TESTING && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/xblat2c.dir/link.txt --verbose=1
/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-4.7.0/prebuilt/darwin-x86/bin/arm-linux-androideabi-gfortran -Wl,--gc-sections -Wl,-z,nocopyreloc -Wl,--fix-cortex-a8 -Wl,--no-undefined -lstdc++ -lsupc++ CMakeFiles/xblat2c.dir/cblat2.f.o -o ../../bin/xblat2c -rdynamic -L/Users/marc/software/lapack-3.4.0/Android/systemlibs/armeabi-v7a -L/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-4.7.0/prebuilt/darwin-x86/user/libs/armeabi-v7a ../../lib/libblas.a -lm -Wl,-rpath,/Users/marc/software/lapack-3.4.0/Android/systemlibs/armeabi-v7a:/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-4.7.0/prebuilt/darwin-x86/user/libs/armeabi-v7a
/opt/local/share/java/android-ndk-macosx/toolchains/arm-linux-androideabi-
4.7.0/prebuilt/darwin-x86/lib/gcc/arm-linux-androideabi/4.7.0/../../../../arm-linux-androideabi/lib/libgfortran.a(c99_functions.o): In function cexpf':
/opt/local/share/java/android-ndk-macosx/src/build/../gcc/gcc-4.7.0/libgfortran/intrinsics/c99_functions.c:910: undefined reference tosincosf'
GCC needs to know at compile time whether sincos is available or not. It does so based on the target. In case of the target triplet arm-linux-androideabi, it looks at gcc/config/linux.h and finds there:
/* Whether we have sincos that follows the GNU extension. */
#undef TARGET_HAS_SINCOS
#define TARGET_HAS_SINCOS (OPTION_GLIBC || OPTION_BIONIC)
The reason for the inclusion of Bionic is that Android 2.3 added support for sincosf/sincos/sincosl [1]. Thus, you can either update Bionic or you patch GCC to assume that no sincos is available; cf. also [2].
[1] http://source-android.frandroid.com/bionic/libc/docs/CHANGES.TXT
[2] https://bugs.launchpad.net/linaro-android/+bug/908125

error Compile shared libraries with -fPIC

While I run snmpd daemon on powerpc board(a.p.) I am getting this error:
R_PPC_REL24: Compile shared libraries with -fPIC!
/usr/local/sbin/snmpd: symbol 'strlen': can't handle reloc type 0xa in lib
/lib/libnetsnmpmibs.so.15'
sh: you need to specify whom to kill
I googled and found that the -fPIC flag should be there while compiling and its place should be right after gcc, so I changed my Makefie accordingly. Here is a snippet of my makefile:
$(Q)cd $(PROJECT_BUILD_DIR)/$(NET_SNMP_PKG) && ./configure --target=$(TARGET_TRIPLET) \
--host=$(HOST_TRIPLET) \
--build=$(BUILD_TRIPLET) \
--with-cc="$(CR_COMPLR)gcc -fPIC" \`
--with-cflags="-Os -I$(RFS)/lib -I$(NMS_DIR)/include" \`
--with-linkcc="$(CR_COMPLR)gcc -fPIC" \`
As you can see I embedded -fPIC right after gcc, but I am still getting an error. I have cross compiled for powerpc platform and I am using latest buildroot-2011.11 and gcc 4.3.6 and uClibc version 0.9.32. What may be the cause of error?
P.S. When I do nm libnetsnmpmibs.so.15 | grep strlen then I get output as U strlen. Does this mean it is undefined?
I got the problem. actually the main thing is to compile with -fPIC only.
In my case I was compiling snmp libraries with -fPIC correctly but some of the functions were dependent on libraries of other packages (nms). As I am working on firmware development there are more than 20 packages involved. So I compiled nms libraries with -fPIC and error is resolved.

How do I install Net::Arping on CentOS 5?

I have tried to install Net::Arping package using cpan and I can't do that because of errors...
CPAN.pm: Going to build R/RI/RIIKI/Net-Arping-0.02.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Net::Arping
cp Arping.pm blib/lib/Net/Arping.pm
/usr/bin/perl /usr/lib/perl5/5.8.8/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.8/ExtUtils/typemap Arping.xs > Arping.xsc && mv Arping.xsc Arping.c
Please specify prototyping behavior for Arping.xs (see perlxs manual)
gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after- statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 - I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack- protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"0.02\" - DXS_VERSION=\"0.02\" -fPIC "-I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE" - D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD -DHAVE_NET_ETHERNET_H Arping.c
Arping.xs: In function ‘XS_Net__Arping_send_arp’:
Arping.xs:116: warning: implicit declaration of function ‘libnet_name_resolve’
Arping.xs:124: warning: passing argument 1 of ‘libnet_select_device’ from incompatible pointer type
Arping.xs:124: error: too many arguments to function ‘libnet_select_device’
Arping.xs:130: warning: implicit declaration of function ‘libnet_open_link_interface’
Arping.xs:130: warning: assignment makes pointer from integer without a cast
Arping.xs:135: warning: implicit declaration of function ‘libnet_get_ipaddr’
Arping.xs:140: error: ‘LIBNET_IP_H’ undeclared (first use in this function)
Arping.xs:140: error: (Each undeclared identifier is reported only once
Arping.xs:140: error: for each function it appears in.)
Arping.xs:143: warning: implicit declaration of function ‘libnet_init_packet’
Arping.xs:148: warning: passing argument 1 of ‘libnet_get_hwaddr’ from incompatible pointer type
Arping.xs:148: error: too many arguments to function ‘libnet_get_hwaddr’
Arping.xs:148: warning: assignment from incompatible pointer type
Arping.xs:156: warning: passing argument 6 of ‘libnet_build_ethernet’ from incompatible pointer type
Arping.xs:156: error: too few arguments to function ‘libnet_build_ethernet’
Arping.xs:161: warning: passing argument 12 of ‘libnet_build_arp’ from incompatible pointer type
Arping.xs:161: error: too few arguments to function ‘libnet_build_arp’
Arping.xs:166: warning: pointer targets in passing argument 1 of ‘pcap_open_live’ differ in signedness
Arping.xs:185: warning: implicit declaration of function ‘libnet_write_link_layer’
Arping.xs:196: warning: implicit declaration of function ‘libnet_close_link_interface’
Arping.xs:197: warning: implicit declaration of function ‘libnet_destroy_packet’
make: *** [Arping.o] Error 1
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
I need this perl module for check_arping script for Nagios.
Some additional informations:
[root#atlantis build]# uname -a
Linux atlantis 2.6.18-238.9.1.el5xen #1 SMP Tue Apr 12 18:53:56 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root#atlantis build]# rpm -qa | grep libnet
libnet-1.1.2.1-2.rf
[root#atlantis build]# rpm -qa | grep libpcap
libpcap-devel-0.9.4-15.el5
libpcap-0.9.4-15.el5
libpcap-0.9.4-15.el5
libpcap-devel-0.9.4-15.el5
[root#atlantis build]#
As You see I've installed libnet, libpcap and still there are problems ... Is anyone have an idea how to resolve this problem?
You have installed libpcap-devel, but not libnet-devel. The *-devel version of an RPM includes C header files that are often required when building XS-based modules.
Try sudo yum install libnet-devel before trying to build the module again.
Update: The advice above was correct, but insufficient. I've just tested this on an installation of Centos 5.6 and it fails with exactly the same errors.
Looking at the CPAN testers results, it's clear that version 0.02 of Net::Arping hasn't built successfully for anyone for a very long time. This distribution was uploaded to CPAN in 2002 and it appears that its XS code just isn't compatible with modern versions of libnet.
There is, however, on CPAN a version 0.03 of Net::Arping. This builds successfully on my Centos 5.6. I suggest you switch to using that instead. I haven't yet worked out why cpan doesn't recognise version 0.03. I see it's by a different author, so it might be a permissions problem. You should consider reporting this issue to modules#cpan.org.

Resources