libtool-patches
[Top][All Lists]
Advanced

[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




reply via email to

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