[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] [mingw] Add cross-compile support to cwrapper
From: |
Charles Wilson |
Subject: |
Re: [PATCH] [mingw] Add cross-compile support to cwrapper |
Date: |
Sat, 17 May 2008 23:39:30 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 |
Roumen Petrov wrote:
Charles Wilson wrote:
[mingw] Add cross-compile support to cwrapper
May be the patch can be more simple. In a previous post I confirm that
for the wine emulator is enough items in path list, where every item is
absolute path from build system, to be separated by DOS path-separator
only.
Right, and thank you for that. What wasn't clear, however, was whether
this automatic path translation was a peculiarity of your wine setup
(e.g. "identity mounts" or something) or is a documented feature of wine.
This is enough and at run-time wine(wineloader?) will translate
internally from "build system absolute path" to the "path from emulated
environment".
So it only works for absolute paths, but is applied to all environment
variables (like PATH)?
winepath will convert relative paths, AFAICT, although it converts them
to absolute first, and canonicalizes if you have permissions to chdir to
the target:
~ $ winepath -w ../<anonther user>
Z:\home\<my_user>\..\<another user>
~ $ winepath -w ../../mnt
Z:\mnt
Also the mapping can be changed after build of package (creation of
cwrapper). So that translated paths (in cwrapper) may point to non
existing more locations in emulated environment.
Well, this is also true of winepath:
$ winepath -w /tmp/nonexistent
Z:\tmp\nonexistent
But I'm not sure that supporting "changing the mapping after building
the wrapper" is something we should support (e.g. deliberately code the
wrapper to allow it, and then have to answer questions about why it does
or does not work in some user's wacky wine setup, down the road.) Is
there a realistic use case where this facility is important, that
couldn't be solved by "okay, then rm -f wrapper.exe, make wrapper"
Also, it's a bit odd to convert the $target_exe path (the argument of
_spawnv) to $host format, but set PATH using $build format path
components. Or does wine's emulation of _spawnv ALSO do automatic path
translation, and we could -- if we choose -- leave ALL paths in $build
format with the exception of s|/|\\|g and s|:|;|g?
I still think we don't want to do /that/ -- see caveats, below.
Please, let me know if you need more info (strace output, dos device
mapping, etc). The test case that I use was posted to the list. In brief:
- library foo1 in ./lib1
- library libfoo2 in ./lib2
- executable foo.exe in ./appl that call functions from foo1 and foo2
libraries.
Well, you didn't actually say whether the existing patch works or not --
just that you think it could be simplified. <g>
Does the current patch work?
The problem I have with "echo $val | sed -e 's|:|;|g'" is what if,
somehow, a dos-style path is in $val?
C:\bob -> C;\bob
(I mean, really: s|:|;|g is bit naive. I was kinda hoping somebody would
give me a better sed expression than the one I'm using in
lt_sed_naive_backslashify...)
Anyway, to avoid C;\bob, I'd need a lot of special casing: if $val
starts with a letter, followed by a ':', followed by an optional '/',
then don't replace the ':', otherwise do. Also, if you see a rooted
relative path (C:bar) which means 'get the drive-specific CWD for drive
C:, and append \bar', then you should flag an error (because you don't
know what the per-drive CWD is within the wine environment)? Or you
should treat as if it is really 'C:\bar' instead, and insert the
"missing" '\' (this is what cygpath does, BTW)?
libtool shouldn't need to worry about these details of one particular
emulation environment. They (the wine people) gave us a path translator
program, we should use it -- and let IT worry about those issues.
Sure, the existing code is a bit ugly, because of winepath's deficiency
(it doesn't atomically convert pathLISTs), but I hope that eventually
winepath WILL support that, and then our ugliness goes away...
P.S.:
Also winepath exit with zero(!?!?!?) even if path cannot be translated:
==============================
$ winepath -w `pwd`; echo $?
Warning: could not find DOS drive for current working directory
'/...../lt-HEAD-mingw-mlib', starting in the Windows directory.
0
Well, that's just...evil. Is it possible that this is a bug in winepath
that should be reported upstream? Surely exit-with-0-on-error is not the
*design* behavior, is it?
I'm going to have to think hard about how to detect error status...there
is a very ugly way to simultaneously redirect stdout to one var, and
stderr to another, but that's just...wrong.
--
Chuck
- [PATCH] [mingw] Add cross-compile support to cwrapper, Charles Wilson, 2008/05/15
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/17
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper,
Charles Wilson <=
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/18
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/20
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Charles Wilson, 2008/05/20
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/21
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Charles Wilson, 2008/05/25
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Charles Wilson, 2008/05/25
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/26
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Charles Wilson, 2008/05/26
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/27
- Re: [PATCH] [mingw] Add cross-compile support to cwrapper, Roumen Petrov, 2008/05/31