problem compiling with gcc, w32api and libiphlpapi.a

cgraham@newobjectivity.com cgraham@newobjectivity.com
Sat Feb 3 16:18:00 GMT 2007


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@dessent.net> wrote:
> cgraham@newobjectivity.com 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
>



More information about the Gcc-help mailing list