From: LRN <lr...@gm...> - 2011-04-27 07:32:11
|
On 27.04.2011 10:57, John Emmas wrote: > 1) Paths - when dealing with absolute paths, does mingw expect them to be in Windows format (with a drive letter at the start) - e.g. "C:\Documents and Settings\some_file". Or does it favour Linux/Cygwin style paths - e.g. "/usr/local/some_file". MinGW tools expect DOS-style paths (c:\windows\...). Msys tools expect *nix-style paths (/c/windows/... or /usr/local/...). Msys will watch process invocations by all Msys tools (including the shell) and will mangle the command line, substituting *nix-style paths for DOS-style paths (see [1] for details). Most (IME) *nix-originated autotools-using projects can not be compiled without using a shell, therefore some kind of Msys shell is mandatory (not sure about non-Msys shell implementations such as zsh), which means that path mangling will be involved. Otherwise (for projects that have their own custom-built Windows/MinGW makefiles or that use buildsystems capable of generating makefiles and that ship them) you might be able to compile with MinGW only and just stick to DOS-style paths everywhere. The programs compiled with MinGW expect DOS-style paths. > 2) Which of these is supported by mingw - fork() / exec() / spawn(). If not supported directly, are they supported by external libs? fork() is not supported exec() is supported by MS C Runtime (though there are differences between POSIX exec() and MSVCR exec()) spawn() is supported by MS C Runtime (again, there are differences) "MS C Runtime" here means that MinGW doesn't have to do anything to support these, they are just forwarded to MSVCR*. > 3) Does mingw support the kind of functions commonly found in unistd.h - e.g. symlink() / readlink() / unlink() etc? Again, if not supported directly, are they supported by 3rd party libs. See [2] for a very recent discussion related to symlinks. In addition: Neither MinGW nor Msys tools support symlinks. Also, since both link to msvcrt instead of msvcrtXX, they, in some cases, might not work with symlinks transparently as you would have wanted. Or might work with symlinks transparently as you would have not wanted. For example: rm -rf /somedir will delete somedir and all of its contents. Even if /somedir is a symlink to c:\foodir. Which means that c:\foodir will be empty after that. Or this: If you symlink /mingw/lib/libws2_32.a to C:\Windows\System32\ws2_32.dll (gcc can link to DLLs directly, but this requires altering library-finding logic; by linking ortodox library names, such as lib/libfoo.dll.a or lib/libbar.a to actual DLLs you can have direct linking without hacking anything), binutils might think that libws2_32.a has size = 0, because stat() from non-symlink-aware msvcrt will say so. Some of that changes if you compile against msys-1.0.dll, but that is for Msys tools only, and if you want to go that far, you'd be better off with Cygwin. [1] http://www.mingw.org/wiki/Posix_path_conversion [2] http://comments.gmane.org/gmane.comp.gnu.mingw.user/36205 |