Re: problem when cross compiling with mingw32ce

[Charles Wilson]

Vincent Torri wrote:
> here is a reminding of something that i reported 2 months ago: (see
> http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html).
> 
> I recall the facts: when using the mingw32ce compiler,
> func_emit_cwrapperexe_src() fails, hence the installation of the
> binaries is not done.
> 
> That function fails because several functions do not exist on that
> platform. They are:
> 
>  * getenv, putenv (no environment variable on that OS)
>  * getcwd (no current working directory feature too)
>  * _spawn()
> 
> The simple way would be to guard them, like it was done with errno:
> 
> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3

Well, not really. The whole purpose of the wrapper (executable, or shell
script on unix platforms) is to *set environment variables*
appropriately before invoking the actual target executable -- especially
$PATH on win32 so that the target executable can "find" the newly-built
and not-yet-installed DLLs that it needs.

How wince handles that with no environment variables I have no idea.
Maybe if it has no directories at all (and hence, no "current working
directory"), then "finding" DLLs it not really an issue. I dunno.

But most of that can be worked-around using stub functions in the
wrapper executable (e.g. wince_setenv() that does nothing and returns
success, etc).  What can't be worked-around is:

_spawn.

Somehow there MUST be a way for one executable on wince to start another
process. Maybe by invoking CreateProcess() directly -- whereas the
normal win32 C runtime provides the _spawn functions as posix-like
wrappers around the core Win32API CreateProcess().

I guess there are two choices: (1) do we need the wrapper (executable)
to "work" -- that is, can you invoke the wrapper executable within the
target environment (a wince emulator, perhaps?) and if so, do we need it
to perform as advertised: set up the proper environment (whatever that
means, if anything, given no env vars) and handover control within the
simulator environment to the actual executable, in .libs/$myexe?

If the answer to either question is no, then perhaps the answer is (2)
just to ensure that the wrapper executable compiles without error, even
if it is utterly non-functional on wince. That's a little...disturbing,
but then, I'm not involved with wince.

FYI: the "re-organized includes and portability macros" part of this patch:
[PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00004.html
was done with an eye toward making these wince workarounds a little
easier. I hope.

Oh, there also might be a third option, but I could be exposing more of
my ignorance: maybe wince could just set $needs_wrapper false always,
regardless of whether the build is static or dynamically linked?

However, what this all boils down to, is somebody is going to have to
write the patch, and test it, using mingw32ce.  That's going to have to
be someone actively involved in using mingw32ce and the wince OS. That
ain't me. And given that your original post was 2 months ago, with
little response, it looks like very few of the list denizens, other than
yourself, have the expertise to directly tackle the problem.

--
Chuck