Re: [Patch] cwrapper invokes target directly
On Tue, 29 Apr 2008, Charles Wilson wrote: If I can get some feedback on the '*_with_wine.sh' script I could update the patch to also support $build=some_unixy_platform_with_wine and $host=mingw. I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I can run Wine on it. I know that Linux has special hooks in order to automatically run Windows executables using Wine. Is the Wine execution support dependent on this Linux feature? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [Patch] cwrapper invokes target directly
On Wed, 30 Apr 2008 10:12:36 -0500 (CDT), Bob Friesenhahn xxx said: I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I can run Wine on it. I know that Linux has special hooks in order to automatically run Windows executables using Wine. Is the Wine execution support dependent on this Linux feature? No, the compile phase requires the $build (linux, unix?) executable 'winepath' only, and does not rely on the binfmt extension present in linux. The wrapper itself is already running in the emulation environment, and uses Win32 spawnv (and other functions from the win32 C runtime library) to launch the target executable -- within the same emulation env, so no need for binfmt there, either. However, actually running the test suite is going to try to invoke the wrapper.exe, so that would require binfmt (or another solution; I have ideas). This may (or may not) represent a regression from 1.5.x+explicit $TARGETSHELL specification, I'm not sure. When I (later) add support for $build=*nix+wine, $host=cygwin cross-compiles, I'll also need either the 'wine' executable (which itself is a $build=*nix program) or the binfmt extension, because I need to execute 'cygpath' *in the $host environment* for step 2 of the following conversion: *nix [$build] path --( winepath )-- native win32 [$host] path --( 'cygpath -u' under wine )-- cygwin [$host] path All of these difficulties and ripples are why I originally thought 'eliminate the wrapper script entirely for $host=cygwin|mingw' was a libtool-2.4 project. However, the current libtool-2.2 behavior was an unreported (!) regression over 1.5.x, and the conversation last week seemed to imply that it was important enough to try to fasttrack before 2.4...but that doesn't mean it will or can get completely fixed in one simple patch. It may require iteration and public testing -- over a few 2.2.x releases -- before we get it right. :-( -- Chuck
Re: [Patch] cwrapper invokes target directly
Charles Wilson wrote: 2008-04-26 Charles Wilson ... [mingw|cygwin] Modify cwrapper to invoke target directly. * libltdl/config/ltmain.m4sh (func_to_native_path): new function. If $host is mingw, and $build is mingw or cygwin, convert path to mingw native format. (func_to_native_pathlist): new function. Ditto, for :-separated pathlists. (func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]: ensure putenv and setenv are declared. Define HAVE_SETENV. (func_emit_cwrapperexe_src) [main]: add new constants to hold desired PATH settings; initialize and convert to native mingw format using functions above. Add new command-line options --lt-env-set, --lt-env-prepend, and --lt-env-append. No longer emit wrapper script as integral part of launching child. Remove support for (now) unnecessary $TARGETSHELL. Exec actual target executable directly. (func_emit_cwrapperexe_src) [lt_setenv]: new function. (func_emit_cwrapperexe_src) [lt_extend_str]: new function. (func_emit_cwrapperexe_src) [lt_split_name_value]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_set]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_prepend]: new function. (func_emit_cwrapperexe_src) [lt_opt_process_env_append]: new function. (func_emit_cwrapperexe_src) [lt_update_exe_path]: new function. (func_emit_cwrapperexe_src) [lt_update_lib_path]: new function. Ping? Okay for push? *Any* comments at all? -- Chuck
Re: [Patch] cwrapper invokes target directly
On Tue, 29 Apr 2008, Charles Wilson wrote: Ping? Okay for push? *Any* comments at all? I forgot that you have the ability to do this by yourself. Ralf says that he has been busy and will soon be unavailable for a week or two. Meanwhile, Gary is wanting to cut a new release on (or before) May 3rd. Since we are trying to pop out new libtool releases a lot more often, can we defer your patch until after Gary cuts the forthcoming release? That way the patch has at least a whole month to be inspected and thoroughly tested before the subsequent release. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [Patch] cwrapper invokes target directly
Bob Friesenhahn wrote: I forgot that you have the ability to do this by yourself. Ralf says that he has been busy and will soon be unavailable for a week or two. Meanwhile, Gary is wanting to cut a new release on (or before) May 3rd. Since we are trying to pop out new libtool releases a lot more often, can we defer your patch until after Gary cuts the forthcoming release? That way the patch has at least a whole month to be inspected and thoroughly tested before the subsequent release. Sure, I can wait. /I'm/ not trying to build in a cross-compile setup for mingw $host, so 2.2.2 works just fine for me. If I can get some feedback on the '*_with_wine.sh' script I could update the patch to also support $build=some_unixy_platform_with_wine and $host=mingw. (The script in question is the #3 attachment to the message that started this thread. It's here http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00164.html and http://article.gmane.org/gmane.comp.gnu.libtool.patches/8429 but in both cases, the attachments all run together...) On another note, I think the $OBJDUMP part of this: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00098.html (that is, all but the first hunk) and this: http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00161.html with the one-liner change mentioned here http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00163.html are suitable for 2.2.4 and it'd be nice to get them in. -- Chuck
