[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem when cross compiling with mingw32ce

From: Vincent Torri
Subject: Re: problem when cross compiling with mingw32ce
Date: Thu, 22 Jan 2009 22:01:33 +0100 (CET)

On Wed, 21 Jan 2009, Charles Wilson wrote:

Vincent Torri wrote:
here is a reminding of something that i reported 2 months ago: (see

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:

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.

there are directories, BUT, and that's one of the incredible issues on that OS (there are others...): the directory is not taken into account when looking for a dll. That is, you should avoid having 2 dll with the same name. Otherwise, only one will be always used. Which one, I don't know. But that's a limitation of the OS. Incredible, isn't it ?

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).

If it's not a problem for the wrapper, it's fine to me.

 What can't be worked-around is:


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().

CreateProcess can be used, I guess. I'm not a windows programmer. I just ported linux libraries to that terrible OS.

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?

I always do cross-compilation for that OS. I compile on linux. Then I copy the dll / binaries with a SD card. So I don't need it, I think

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.
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.

I can provide patches, but, as I already said, I'm not involved in libtool dev and I can't write patches if i'm not helped. I have not time to dig into libtool code, as i already have not a lot of time to work on my own todo list. I can compile libtool, run tests, see if my libs compiles flawlessly with libtool.

So, according to what I've said, what do you think it is best for that wrapper ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]