Winsrc compilation

[GoogleCodeExporter]

After downloading the latest SVN on 10-10-2009 I ran into a problem
compiling on Windows using the ProxSpace found at
http://proxmark3.googlecode.com/files/2 … xSpace.zip

Visual studio 9 does not like strncasecmp. And resulted in the following error:

cl /W3 /nologo /Zi /MT /Fdobj/vc90.pdb /I"..\..\devkitWIN"\include
/D_WIN32_WINN
T=0x501 /DISOLATION_AWARE_ENABLED /D_WIN32_IE=0x600 /DWIN32_LEAN_AND_MEAN
/DWIN3
2 /D_MT /D_CRT_SECURE_NO_WARNINGS -c -Foobj/command.obj command.cpp
command.cpp
command.cpp(2837) : error C3861: 'strncasecmp': identifier not found
command.cpp(2839) : error C3861: 'strncasecmp': identifier not found
command.cpp(2841) : error C3861: 'strncasecmp': identifier not found
command.cpp(2843) : error C3861: 'strncasecmp': identifier not found
make: *** [proxmark3] Error 2

In order to resolve this I added the following lines to command.cpp
starting at line 21.

#if defined(_WIN32) || defined(_WIN64)
#define strncasecmp _strnicmp
#endif

Also the Makefile in winsrc contained the following line:
BASE_DIR    ?= "..\..\devkitWIN"

The quotes could be an issue depending on the  build environment.  I
changed the line in my source to the following:
BASE_DIR    ?= ..\..\devkitWIN

Attached is the diff for the files.

Original issue reported on code.google.com by bran...@akisu.com on 16 Oct 2009 at 2:31

Attachments:

• winsrc.patch

[GoogleCodeExporter]

bushing has recently completely revamped the windows build process to not use
Microsofts compiler anymore, so I believe this problem should be gone now.

(Note that of course you might run into new issues when setting up the new build
environment, we currently don't have an illustrated step-by-step guide on that.)

http://www.proxmark.org/forum/topic/422/client-working-under-os-x/

Original comment by henryk.m...@googlemail.com on 23 Dec 2009 at 6:10

[GoogleCodeExporter]

Yep this can add loads of problems.

First, the current version of gnu make 3.81 is broken at least with MinGW and 
doesn't
handle shell very well resulting in the following error trace when trying to 
make the
prox client:

C:\ProxSpace\proxmark3-svn\client>c:\MinGW\bin\mingw32-make
cc -I. -I/opt/local/include -Wall -Wno-unused-function    -c -o proxmark3.o prox
mark3.c
process_begin: CreateProcess(NULL, cc -I. -I/opt/local/include -Wall -Wno-unused
-function -c -o proxmark3.o proxmark3.c, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** [proxmark3.o] Error 2

This problem is briefly described in the following thread on nabble.  There are 
some
patches for this.
http://old.nabble.com/process_begin:-CreateProcess%28NULL,-%22%22,-...%29-failed
-td16106327.html

I typically use Cygwin so the make issue didn't appear for me on one of my VMs 
but it
may very well show up if someone tries to build with MinGw.

With a non-broken GNU make I ran into the the following compilation error trace:

C:\ProxSpace\proxmark3-svn-12-23-2009\cockpit>3makewin.bat
**************
*** client ***
**************
cc -I. -I/opt/local/include -Wall -Wno-unused-function    -c -o proxmark3.o 
proxmark3.c
proxmark3.c: In function `usb_receiver':
proxmark3.c:42: warning: control reaches end of non-void function
proxmark3.c: In function `main_loop':
proxmark3.c:78: warning: control reaches end of non-void function
cc -I. -I/opt/local/include -Wall -Wno-unused-function    -c -o gui.o gui.c
cc -I. -I/opt/local/include -Wall -Wno-unused-function    -c -o command.o 
command.c
command.c: In function `CmdLoCommandRead':
command.c:713: warning: int format, uint32_t arg (arg 3)
command.c:713: warning: int format, uint32_t arg (arg 4)
command.c:713: warning: int format, uint32_t arg (arg 5)
command.c:713: warning: int format, uint32_t arg (arg 3)
command.c:713: warning: int format, uint32_t arg (arg 4)
command.c:713: warning: int format, uint32_t arg (arg 5)
command.c: In function `CmdTIWrite':
command.c:1502: warning: unsigned int format, uint32_t arg (arg 3)
command.c:1502: warning: unsigned int format, uint32_t arg (arg 4)
command.c:1502: warning: unsigned int format, uint32_t arg (arg 5)
command.c:1502: warning: unsigned int format, uint32_t arg (arg 3)
command.c:1502: warning: unsigned int format, uint32_t arg (arg 4)
command.c:1502: warning: unsigned int format, uint32_t arg (arg 5)
cc -I. -I/opt/local/include -Wall -Wno-unused-function    -c -o usb.o usb.c
usb.c: In function `OpenProxmark':
usb.c:143: warning: implicit declaration of function 
`usb_detach_kernel_driver_np'
cc -I. -I/opt/local/include -Wall -Wno-unused-function    -c -o guidummy.o 
guidummy.c
cc   proxmark3.o gui.o command.o usb.o guidummy.o  -L/opt/local/lib 
-L/usr/local/lib
-lusb -lreadline -lpthread  -o proxmark3
usb.o:usb.c:(.text+0x3eb): undefined reference to `_usb_detach_kernel_driver_np'

collect2: ld returned 1 exit status
make: *** [proxmark3] Error 1

The non-void issue has shown up a number of times as a gcc issue. The last time 
I ran
into the "unsigned int format, uint32_t" warning it was due to a messed up 
header
somewhere. I haven't bothered checking any header files to fix the warnings yet 
but
the undefined reference to _usb_detach_kernel_driver_np is due to the _np call 
being
non portable and the
#ifndef __APPLE__ 
lines that it lives between in client/usb.c when __APPLE__ doesn't appear to be
defined anywhere by anything.  (I only ran a grep -lR on the svn in windows so
perhaps it missed something)  Perhaps this should be changed to a #ifdef 
__APPLE__

One other minor issue is the hard coded WINCC path in the client Makefile.

BTW I would be happy to help work on putting together a newer ProxSpace binary
distribution and howto if we can get the cockpit and Makefile code a little more
settled.  I have been working on some modules to the codebase from a few months 
ago
which seems to break a bit when trying to patch the current svn.  I will submit 
them
when they work properly.

Original comment by bran...@akisu.com on 25 Dec 2009 at 4:47

[GoogleCodeExporter]

What's the current state of this issue?
What are the steps to reproduce this problem?

If possible, please describe the actions you had to take in order to the solve 
the problems.

Thanks!

Original comment by ksjob...@gmail.com on 7 Apr 2010 at 9:03

[GoogleCodeExporter]

As I see: there is no problem at rev r469.

Original comment by oleg...@gmail.com on 25 May 2011 at 4:15

[GoogleCodeExporter]

Original comment by verdult on 8 Mar 2013 at 8:44

• Changed state: Fixed