I am interested in compiling windows for Python25 support but when I
make -f Make_ming.mak gvim.exe
I get the following (_MAX_PATH undeclared):
gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -DFEAT_PYTHON -I c:/Python25/include -DDYNAMIC_PYTHON -DYNAMIC_PYTHON_DLL=\"python25.dll\" -O3 -fomit-frame-pointer -freg-struct-return -s fileio.c -o gobj/fileio.o
fileio.c: In function `buf_modname':
fileio.c:5877: error:_MAX_PATH' undeclared (first use in this function)
fileio.c:5877: error: (Each undeclared identifier is reported only once
fileio.c:5877: error: for each function it appears in.)
fileio.c: In function `vim_tempname':
fileio.c:6832: error: `_MAX_PATH' undeclared (first use in this function)
make: *** [gobj/fileio.o] Error 1
Any ideas? What am I missing?
Thanks.
I don't how to fix your problem myself, but I followed this video tutorial to do exactly what you are trying and it worked like a charm:
http://showmedo.com/videotutorials/video?name=1850010&fromSeriesID=185.
If you want the Vim text editor, why are you not using the download version(s) from vim.org, etc. (gvim, Cream, Portable Gvim)
If you are trying to build Python for windows, why are you not using the current 2.6.1 or 3.0.1 from python.org?
_MAX_PATH should maybe be PATH_MAX or _PATH_MAX which is defined via stdlib.h / limits.h or sys/param.h under Linux.
Have you checked any configuration logs? Any previous compiler warnings about missing includes or undefined values? Search for PATH_MAX and PATH_MAX.
Is it just for the support of Python 2.5?
Not the answer to your question, but the easy way:
downloaded the precompiled vim.exe and gvim.exe from gooli.org (for Python 2.5 and/or 2.6)
Related
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.
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.
I have searched high and low for a solution. I have both linecache19 and ruby_core_source installed.
Neither of these commands will work:
gem install ruby-debug19
gem install ruby-debug19 -- --with-ruby-include=/Users/benjohnson/.rvm/src/ruby-1.9.1-p378
Here is the error I keep getting:
Building native extensions. This could take a while...
ERROR: Error installing ruby-debug19:
ERROR: Failed to build gem native extension.
/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/bin/ruby extconf.rb
checking for rb_method_entry_t.body in method.h... no
checking for vm_core.h... no
checking for rb_method_entry_t.body in method.h... no
checking for vm_core.h... yes
checking for iseq.h... yes
checking for insns.inc... yes
checking for insns_info.inc... yes
checking for eval_intern.h... yes
creating Makefile
make
gcc -I. -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/i386-darwin10.4.0 -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby/backward -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1 -I. -DHAVE_VM_CORE_H -DHAVE_ISEQ_H -DHAVE_INSNS_INC -DHAVE_INSNS_INFO_INC -DHAVE_EVAL_INTERN_H -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby-1.9.1-p378 -fno-common -O2 -g -Wall -Wno-parentheses -fno-common -pipe -fno-common -o breakpoint.o -c breakpoint.c
gcc -I. -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/i386-darwin10.4.0 -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby/backward -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1 -I. -DHAVE_VM_CORE_H -DHAVE_ISEQ_H -DHAVE_INSNS_INC -DHAVE_INSNS_INFO_INC -DHAVE_EVAL_INTERN_H -I/Users/benjohnson/.rvm/rubies/ruby-1.9.1-p378/include/ruby-1.9.1/ruby-1.9.1-p378 -fno-common -O2 -g -Wall -Wno-parentheses -fno-common -pipe -fno-common -o ruby_debug.o -c ruby_debug.c
ruby_debug.c: In function ‘ruby_method_ptr’:
ruby_debug.c:141: error: ‘rb_method_entry_t’ undeclared (first use in this function)
ruby_debug.c:141: error: (Each undeclared identifier is reported only once
ruby_debug.c:141: error: for each function it appears in.)
ruby_debug.c:141: error: ‘method’ undeclared (first use in this function)
ruby_debug.c:142: warning: implicit declaration of function ‘rb_method_entry’
ruby_debug.c: In function ‘debug_event_hook’:
ruby_debug.c:719: error: ‘rb_method_entry_t’ undeclared (first use in this function)
ruby_debug.c:719: error: ‘me’ undeclared (first use in this function)
make: *** [ruby_debug.o] Error 1
Gem files will remain installed in /Users/benjohnson/.rvm/gems/ruby-1.9.1-p378/gems/ruby-debug-base19-0.11.24 for inspection.
Results logged to /Users/benjohnson/.rvm/gems/ruby-1.9.1-p378/gems/ruby-debug-base19-0.11.24/ext/ruby_debug/gem_make.out
I have had the same issue (on 1.9.1 and 1.9.2). Even trying to install 0.11.23 triggered the error. I found that it was necessary to:
Uninstall the gem (all versions for me):
gem uninstall ruby-debug-base19
Delete the 0.11.24 directory (in my case: ~/.rvm/gems/ruby-1.9.2-p0/gems/ruby-debug-base19-0.11.24/)
install 0.11.23 explicitly:
gem install ruby-debug-base19 --version=0.11.23
This is where I got most of the solution: http://rails.brentsowers.com/2010_08_01_archive.html
Additionally, if you use Bundler:
I had problems until I upgraded to latest Bundler (1.0.2 => 1.0.7) as it insisted on installing ruby-debug-base19 v 0.11.24).
In your Gemfile, make sure you've pinned the version of ruby-debug-base19:
gem "ruby-debug-base19", "0.11.23", :require => nil
This one works best for me, because it don't seems too hackish:
gem install ruby-debug19 -- --with-ruby-include=$rvm_path/src/ruby-1.9.2-head/
don't forget to set $rvm_path.
In my case, the last folder was ruby-1.9.3-head - pick the right one for you.
got this answer from here: ruby-debug install error: failed to build gem native extension
on Debian/Ubuntu/Mint this issue could be solved by installing some of these packages (I'm not sure which is causing the problem)
apt-get install libcurl4-openssl-dev libgcrypt11-dev libgnutls-dev
libidn11-dev libldap2-dev librtmp-dev libtasn1-3-dev m4
Do you have gcc installed and path to gcc.exe referenced in your PATH environment variable?
This solved similar problem for me, probably this could your solution too!
For the version of ruby I was working with I had to add both of these lines to my Gemfile
gem 'ruby-debug-base19', '0.11.23'
gem "ruby-debug19"
I am trying to cross-compile linux for an ARM architecture.
The host is an X86 machine running ubuntu-jaunty. I downloaded a cross-compile toolchain for ARM from http://ftp.arm.linux.org.uk/pub/armlinux/toolchain/. I downloaded the 2.95.3 version of the toolchain.
The problem I am having is that GCC is passing in some default flags by itself that is causing GCC to then output error:
/usr/local/arm/2.95.3/bin/arm-linux-gcc -specs=/home/feroze/wnr834m/marvell_WNR834M/gcc_specs -D__KERNEL__ -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -DLED_DUAL_COLOR -DFOR_ROUTER -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/arch/arm/mach-mv88fxx81/Soc/gpp/ -Uarm -fno-common -pipe -mapcs-32 -D__LINUX_ARM_ARCH__=5 -march=armv5 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm -march=strongarm -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
cc1: bad value (strongarm) for -march= switch
make[1]: *** [init/main.o] Error 1
make[1]: Leaving directory `/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk'
I checked the whole makefile, and could not find any place where LINUX_ARM_ARCH_5 and -march=armv5 are being defined. I am defining -march=strongarm in the makefile, but then it gets appended by theh ARMv5 defines.
So, I created a defs file from gcc, modified it to only have options for ARMv4, and then used it by specifying the -specs= option. However, that still doesnt solve the problem.
Can somemone help? How do I resolve this?
Thanks!
feroze
The -march flag is set in arch/ARM/Makefile, and depends on the machine you selected in your config file. If you don't want the armv5 flag, be sure to select the correct architecture in the config file.
You should assume the kernel appended CFLAGS are right (provided your config is ok) and if your toolchain does not support one of them, then you have no choice but to cross compile a toolchain by yourself, using the original crosstol script that should work with 2.95.3
Edit : original answer
What are you trying to build ?
a 2.95.3 toolchain is fairly ancient. You should try a more recent toolchain. You can find a precompiled one here
Pick the EABI one to start.
This is not a direct answer to your problem, but if you are building the linux kernel, you should not need to mess with the Makefiles. You will get more help if you can get a more "standard" toolchain.
This won't strictly help you eliminate the issue, but you can do gcc -dM -E <empty_file.c> or gcc -dM -E -x c /dev/null to print out a listing of all the predefined #defines for gcc. Combine -dM with another flag like your -march and you might be able to track down what's causing your #define issue.
Be sure to check your environment variables, as they can persuade make to do unexpected things.
If the Makefile includes another file, it could be modifying CFLAGS before CC is called. Can you print the contents of CFLAGS just before the CC call?
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.