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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool