JonY writes:

> On 5/26/2012 00:32, Alberto Luaces wrote:
>> Hello,
>> 
>> I'm trying to deploy a DLL to be run in a windows-based, embedded
>> device.  In order to compile it, I have used mingw w64.  The DLL works
>> fine on windows in a regular PC.  However, it fails to load when the
>> used from the device.  The reason is that the device has a MSVCRT.DLL
>> library that lacks some functions that seem that are expected in
>> programs compiled with mingw w64.  So far, __setusermatherr is not
>> defined there, and some more symbols might not be found in advance.
>> 
>> I thought of building a mingw w64 toolchain not relying on MSVCRT.DLL,
>> by using newlib instead, but I'm having trouble doing that: latest
>> newlib expects libppl=0.10 and the latter doesn't compile on my system
>> (but libppl 0.12 does)...  so I guess maybe it is better to seek for
>> advice on this list about having a mingw w64 toolchain whose produced
>> binaries don't rely on MSVCRT.DLL.  Specifically I would be interested
>> on seeing how other people build their own cross-compilers for embedded
>> systems, dealing with the libc issue.
>
> Well, you're the first to try mingw-w64 for an embedded Windows, so I
> wouldn't expect it to go smoothly. It'll take some modifications to
> continue.
>
> The best way to find out is generate the def files for the embedded
> gdi32, comdlg32, user32, kernel32, advapi32, shell32 and msvcrt DLLs.
> You can look for the gendef tool to help you out.
>

Thanks for the help, JonY.  Oddly enough, msvcrt seemed to be placed in a
non-readable (at least by the user) partition, so the only information
that I had was the error message about __setusermatherr.

Following your advice, I commented out the __setusermatherr from the
.def file for msvcrt, and recompiled the run-time.  Not surprisingly, at
link time an error about an undefined symbol called __setusermatherr was
shown.  I wrote an empty function in order to provide that symbol by
myself.  I expect this not to be problematic since I don't call that
function directly, and if it was gfortran or gcc the one that did, I
guess that should not be too harmful: I can live without mathematical
error management in the embedded environment.

Now the dll loads successfully and also seems to run fine on the embedded
machine.

Thanks again!

-- 
Alberto


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to