René Berber <r.berber <at> computer.org> writes: > > What you usually do on those cases: > > 1. On the build host, run ldd (or cygcheck) on the program, see the full > list of dynamic libraries used. > > 2. Try to do the same on the target host. Yes, ldd does depend on > cygwin1.dll, so it may not run. cygcheck doesn't depend on the > cygwin1.dll . I'll do some more of this next week when back at work. I did do cygcheck -s -v -r on the target (from the Cygwin Reporting Problems page) but it produced no output.
> > I can do the same on any desktop PC running Windows XP, or 7, my "Hello > > World" runs as expected. > > For completeness sake, you mean a PC where Cygwin has not been installed? That is correct > > > In discussing this with the embedded PC supplier, he suggests that the > > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this > > explanation plausible? > > I don't know, but I doubt it. As long as it is compatible with the > Intel x86 architecture, and Windows is a "complete" version, it should work. That is what I had expected... > > Cross-compilation from Cygwin to Win32 (MinGW, MinGW-w64) is still > possible, just needs a different set of tools which are available in the > Cygwin distributed packages. Actually is a better option in your case, > unless you really want to use a long list of libraries which may not be > ported to Win32, or build programs intended for Unix/Linux. My reason for using Cygwin was so as to re-use code originally written for Linux with POSIX serial ports etc. Thank you for your help. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
