POLINK: invalid machine type

[drgott]

skyhookwireless has a library for accessing its cell tower/wifi hotspot databases for geolocation.  sdk is available for numerous platforms, among which, windows mobile. 
the 3 files of interest are: wpsapi.lib,wpsapi.dll and wpsapi.h.  the .dll goes on the device, the .lib is used by polink and goes in the pellesc\lib\wince sub-directory, the .h goes in with the project.
a test app - compiled by skyhookwireless - is included with the sdk.  copy it to the device, and it runs perfectly, so presumably i've got the correct .dll, at least. 
when i build my project, now using wpsapi.lib, i get the following error:
polink: fatal error: invalid machine type in object wpsapi.dll   error 1

1) the project has been built and rebuilt (on the desktop), and the app run and rerun (on the device) hundreds of times, so building is targeted correctly.
2) the only new wrinkle is the skyhookwireless library.  there are basically only 2 hooks, and they fit in place fine (at least as far as the compile is concerned.)
3) so how does polink know there is an invalid machine type in object wpsapi.dll?  that object is not on the desktop.  what does it think it's looking at?  (and, yes, i have built the project when the .dll was still on the desktop after downloading the sdk.  i get the same error either way.)
4) besides, the .dll works on the device, so what invalid machine type are we talking about?
5) i'm guessing polink is trying to tell me something, but i don't think it actually has to do with an invalid machine type in the .dll..
thanks for any thoughts.

-george ott

[Stefan Pendl]

polink: fatal error: invalid machine type in object wpsapi.dll   error 1

Pelles C supports the ARM processor for mobile devices only, so this tells us, that the DLL is created for a different processor type.

[frankie]

Have you set the compiler for ARM processor?
In the IDE set Tools->Project->Project_Options->Machine = ARM
If you compile and link from command line use the switch /Tarm or /Tarm-coff for POCC and /machine:arm for the linker.
When have problems like this would be better to have a look to the help. Generally you can find the right solution faster.

[drgott]

to stefan and frankie -  thanks for your comments, but, as i indicated:
1) the .dll is on the device, and it functions fine when used by the sample app included in the sdk.  the device has an arm processor, so - to my mind - that would tell us the .dll has been targeted correctly, no?
2) since the .dll is not on the desktop (and, to be safe, the device was not connected to the desktop during the build), how could polink possibly know anything about what is in the .dll?  it can't even see it.  and - refer to #1 - in any case, the .dll works on my arm device, so wouldn't that mean it was built for arm?
3) all the compiler/linker switches you mention were already set; as i indicated, the project - minus the wpsapi hooks - has been functioning on the device for months.  the only changes to the project are the addition of 2 wpsapi-related functions, the inclusion of wpsapi.h and the addition of wpsapi.lib to the linker.  i don't see how the .dll enters the building phase at all.  the app will look for it when it runs on the device.

what is telling polink that there is an error in an object it cannot see?  could it mean to say something else? 

[TimoVJL]

Use podump.exe to examine wpsapi.lib

For example podump.exe cemapi.lib

Code: [Select]

...
Member at offset CD2: CEMAPI.dll/
478401EF time date stamp (Wed Jan  9 01:06:23 2008)
         user id
         group id
  100666 mode
      9A size
Correct end of header

FILE HEADER
     1C0 machine (ARM)
       2 number of sections
478401EF time date stamp (Wed Jan  9 01:06:23 2008)
      6C offset to symbol table
       1 number of symbols
       0 size of optional header
     100 characteristics:
           32 bit word machine
...

[drgott]

thanks, timovjl
one step closer, maybe.  i get the feeling you're suggesting the "error" is in .lib, not necessarily in the .dll (especially since the .dll seems to be fine.)
when i run podump against wpsapi.lib, the output is quite different from your example.  i get simply:
file type: LIB
SUMMARY
C0 .debug$S
14 .idata$2
14 .idata$3
 4  .idata$4
 4  .idata$5
 C  .idata$6

i see there is a slew of switches for podump, so i'll work through them to see if the output changes.  thanks for the hint.
ii do know that the .lib and, presumably, the .dll were built with MS tools.  i'm guessing there may be a compatability issue.
in any case, for what it's worth, i successfully built the project on my w7 desktop for the the desktop, so compatibility may not be the problem.
i was not able to find a list of machine types, so thanks again for indicating the value for arm.

- george ott

[drgott]

timovjl -  podump /headers gets it!  machine type=1c2.  what's a thumb?

[frankie]

The lib file for DLL is a pseudolibrary file, meaning that it only holds offset for image table to link to the DLL at loading time. So if you get a DLL error during link phase is always referred to data in the lib file (the linker doesn't care of the DLL file).
If the DLL and library you have is compiled for use of ARM THUMB instructions set (Optimized 16 bit instruction set) you cannot link it with PELLESC.
PELLESC only supports standard 32 bits ARM instructions (See help file).
You can only recompile DLL from sources with PELLESC (that will not generate thumb instructions).
A dirty solution is, if you know that thumb instructions are not used, to touch the lib file changing the machine code (Not guaranteed to work).

[TimoVJL]

You can try to recreate import library like this:

polib.exe /machine:arm wpsapi.dll -out:wpsapice.lib

Put that library to your test directory with wpsapi.h

Then you can try compile this. It is for compiling/linking test only.

Code: [Select]

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include "wpsapi.h"

#pragma lib "wpsapice.lib"

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpszCmdLine, int nCmdShow)
{
const char* paths[]={"foo", NULL};
WPS_set_local_files_path(paths);
return 0;
}

With PEView.exe you can examine dll/lib files.
http://www.magma.ca/~wjr
http://www.magma.ca/~wjr/PEview.zip

[drgott]

a thank you to frankie and thanks plus 2 stars to timovjl.
polib (per timovjl) builds an arm-targeted .lib.  when linked to new .lib, probject builds perfectly.
i made note of frankie's comment about the .dll possibly containing thumb-specific code, crossed my fingers and tried the project on my arm device.  no crash, no system errors.  now i just have to figure out what skyhook is supposed to do and create some meaningful output.  skyhook's samples are mfc managed stuff, so i'm holding my nose and taking a look.  thanks again for a quick resolution.

[drgott]

just a brief followup (in case anybody is interested in checking out skyhook), read this thread and follow the suggestions.  everything works as expected when they are implemented.  thanks again to timovjl, frankie and stefan.  skyhook has been informed of the error message and subsequent findings.