cgraham@xxxxxxxxxxxxxxxxxx wrote:
> I am trying to write a program that will allow me to get the MAC address on
> a windows machine. I am using cygwin and gcc to build a dll that I can get
> the mac address in java JNI.
>
> here is the cpp file:
You really should consider using MinGW here and not Cygwin. You can use
MinGW from inside Cygwin by just using the -mno-cygwin flag.
Dynamically loading a DLL that is linked against cygwin1.dll is
problematic, it takes special steps. But you don't have to do anything
special with a regular MinGW DLL. And you're not using any POSIX
functions so you don't need the Cygwin emulation.
> $bash>gcc -g -v -I"/cygdrive/c/java/jdk1.5.0_08/include"
> -I"/cygdrive/c/java/jdk1.5.0_08/include/win32" -I"/cygdrive/c/cygwin/usr/include/w32api" -I"/usr/include/mingw" -Wall -L"/usr/lib/w32api" -L"/usr/lib" -liphlpapi -lnetapi32 -lcap -lws2_32 -ldpnet WindowsMacFinder.cpp
You are in very shaky ground by trying to do -I/usr/include/mingw but
not including -mno-cygwin. Expect tons of problems if you try to mix
headers between MinGW and Cygwin like that. If you do specify
-mno-cygwin, this switches everything into MinGW mode, meaning you don't
need to specify -I/usr/include/mingw. But if you stick with a Cygwin
gcc (i.e. no -mno-cygwin) then you can't use MinGW headers. Consider
the two completely separate, you cannot mix and match.
And in either case, -L"/usr/lib/w32api" -L"/usr/lib" are both totally
extraneous as they are searched by default. You probably added them to
try to resolve your link problem, but that problem was not due to the
linker not being able to find the libraries. If that had been the case,
it would have said "unable to find -lwhatever", not an unresolved symbol
error.
The order that you specify things here matters. The linker examines
objects from left to right, and hence if something later in the command
uses a symbol from something that preceded it, the link will fail
because the linker didn't know that it needed that symbol when it first
saw the object. In other words, put things in their dependancy order.
This usually means "-lfoo" comes last, after all source files.
A lot of people trip this up without ever knowing it, because on ELF
platforms like Linux there is lazy binding, meaning that symbols can be
left unresolved at link-time and they will be resolved at runtime by
ld.so. This is not the case with PE, where all symbols must be resolved
at link time, and thus you can't get away with specifying things to the
linker in the wrong order.
> and it cannot find the windows stuff when it compiles:
>
> /cygdrive/c/DOCUME~1/cgraham/LOCALS~1/Temp/cc7KntVs.o: In function
> `GetMACaddress':
>
> /cygdrive/c/clay/projects/jnitest/src/c/WindowsMacFinder/WindowsMacFinder.cpp:23: undefined reference to `_GetAdaptersInfo@8'
It can't resolve this reference because when it scanned -liphlpapi it
had not yet seen WindowsMacFinder.o, and so it had no idea that it
needed to add GetAdaptersInfo from -liphlpapi into the link.
> /usr/lib/libcygwin.a(libcmain.o):(.text+0xab): undefined reference to
> `_WinMain@16'
This is because you didn't provide a main() function, which is a
requirement to build an .exe, which is what you get if you don't specify
-shared. You're trying to build a DLL, so you need -shared.
gcc -O2 -g -Wall -mno-cygwin -shared -o WindowsMacFinder.dll \
-I/cygdrive/c/java/jdk1.5.0_08/include \
-I/cygdrive/c/java/jdk1.5.0_08/include/win32 \
WindowsMacFinder.cpp -liphlpapi -lnetapi32 \
-lcap -lws2_32 -ldpnet
Brian
