On Fri, 12 Nov 2004, Kamal R. Prasad wrote:

>>     If the library really doesn't make any external calls then you
>>     should just be able to objcopy to convert it to elf and link it
>>     into a NetBSD binary (with a possibly a little glue to match up
>>     function calling semantics).
>> 
> You mean,
> # objcopy -I windows_filename -O netbsd_filename
>
> will automatically make it a netbsd usable library?

 	Something more like 'objcopy -O elf32-arm infile outfile'
 	would give you an elf compatible library. I've not done this
 	personally but hopefully someone else can chime in.

>>     If it makes some external library calls such as malloc() then
>>     you need to include another library which provides a 'windows'
>>     wrapper to the native version of those functions (if the calling
>
> The external functions called are the std libc functions. Its likely that the 
> function prototypes don't change across platforms because of standardization.

 	Hopefully.

>>     semantivcs are different) - the PEACE project is a good example of
>>     a more complete version of this
>>     http://chiharu.haun.org/peace/status.html
>> 
> This seems to  be a work in progress.
>
>>     Is there no way you could get the vendor to provide the object
>>     code in native NetBSD form?
>> 
>>     Its relatively simple to setup a windows box to compile
>>     NetBSD/arm32 binaries. Maybe if you offered to build a toolchain
>>     (donwload NetBSD and './build.sh -m evbarm toolchain' :)
>>     and asked them to compile the source using it?
>> 
> Not a v. cooperative/competent vendor.

 	I'd start by compiling a trivial function that just doubles
 	the argument and returns the result under WinCE arm and to a .a,
 	objcopy and test the result works, then try the other lib.

 		David/absolute       -- www.NetBSD.org: No hype required --