Thread: lwIP & winpcap linking shenanigans

Hello everyone,

I've been trying to get a simple lwIP app up and running under win32, but I seem to be stuck with a rather mystifying LNK2001 error:

Code:

1>udptest.obj : error LNK2001: unresolved external symbol "signed char __cdecl ethernetif_init(struct netif *)"[...]
1>udptest.obj : error LNK2001: unresolved external symbol "void __cdecl ethernetif_poll(struct netif *)"[...]
1>udptest.obj : error LNK2001: unresolved external symbol "void __cdecl ethernetif_shutdown(struct netif *)"[...]

The basis for my code is the official win32 port of lwIP, available here - I managed to compile the necessary libraries (and the test program included within as well). Then I created a new project for my own app and proceeded to adapt its linker configuration to use those libraries, producing the command line below:

Code:

/OUT:"C:\Users\sh4r3\Documents\Visual Studio 2008\Projects\udptest\Release\udptest.exe"
/INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Users\sh4r3\Documents\Visual Studio 2008\Projects\udptest\\Lib"
/MANIFEST /MANIFESTFILE:"Release\udptest.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT
lwip.lib pktif.lib  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib 
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib

However, if I try to reference my routines according to this guide, I get an empty dialog box with no sign of those two libraries whatsoever. It's quite confusing - none of the lwIP function calls trigger a linking error, only those going to the packet interface library (same libpath, btw)... I'd be grateful for any assistance that could fix this weird error.

Originally Posted by LitmusConfig

Hello everyone,

I've been trying to get a simple lwIP app up and running under win32, but I seem to be stuck with a rather mystifying LNK2001 error:

Code:

1>udptest.obj : error LNK2001: unresolved external symbol "signed char __cdecl ethernetif_init(struct netif *)"[...]
1>udptest.obj : error LNK2001: unresolved external symbol "void __cdecl ethernetif_poll(struct netif *)"[...]
1>udptest.obj : error LNK2001: unresolved external symbol "void __cdecl ethernetif_shutdown(struct netif *)"[...]

The basis for my code is the official win32 port of lwIP, available here - I managed to compile the necessary libraries (and the test program included within as well). Then I created a new project for my own app and proceeded to adapt its linker configuration to use those libraries, producing the command line below:

Those are linker errors.... what library are those calls in?

You probably need to add the library to your project options...

lwip.lib and pktif.lib , both compiled from the lwIP project I linked above.

(Background info: the actual app will be running on a MicroBlaze core but I have limited access to the FPGA devkit, so to speed up development I thought I'd use the win32 port at home. If I can get it to work at all, that is.)

And are those libraries in any path where the linker can find them?

I looked at the command line above and really couldn't tell....
You should note however that the end of your lib path has ... updtest\\lib ... which might be part of the problem

Yeah, the extra slash is there because the '$(SolutionDir)' expression in the Configuration Properties \ Linker \ General \ Additional Library Directories entry seems to resolve in a counter-intuitive way. It's just a cosmetic difference though, the result is the same even when I use an explicit path to where the .libs reside.

Ok, then I'm stumped.

Maybe someone else?

Thanks, I never thought of that! nm in mingw lists the symbols with t/T flags (I understand that's OK, right?), and the relevant outputs from dumpbin /symbols look like:

Code:

01F 00000000 SECT9  notype ()    External     | _ethernetif_shutdown
025 00000000 SECTB  notype ()    External     | _ethernetif_poll
03D 00000000 SECT12 notype ()    External     | _ethernetif_init

I don't suppose the leading underscore can cause any problems since all the symbol names in lwip.lib have that as well and those work just fine, so... weird.

Salem makes a good point here... check your calling convention in your settings... if it's set to stdcall this might explain your errors.... since the linker would then be looking for @FunctionName instead of _FunctionName...

Thanks for the help, that was indeed the culprit!