Brian, Thank you so much for your informative and verbose response. It *really* helped me resolve the issue. Now that I have it working I am going to write a cookbook for JNI and gcc and I will make sure to post it to the list. mega thanks from a newbie. Clay On February 2, 10:50 pm Brian Dessent <brian@xxxxxxxxxxx> wrote: > 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/cygwi > > n/usr/include/w32api" -I"/usr/include/mingw" -Wall -L"/usr/lib/w32api" - > > L"/usr/lib" -liphlpapi -lnetapi32 -lcap -lws2_32 -ldpnet WindowsMacFinde > > r.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/WindowsMac > > Finder.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 >
