Re: problem when cross compiling with mingw32ce

[Vincent Torri]

On Wed, 21 Jan 2009, Charles Wilson wrote:

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

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

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

ok

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

Vincent