From: Earnie B. <ea...@us...> - 2005-08-11 00:37:50
|
On 4:41:16 pm 2005-08-10 "Max T. Woodbury" <ma...@mt...> wrote: > Earnie Boyd wrote: > > > > On 3:02:06 pm 2005-08-10 "Max T. Woodbury" <ma...@mt...> > > > wrote: As you are probably aware, I am trying to identify the > > > canonical sources for to tools used in MinGW and MSys and > > > rebuild each from scratch. I'm in the process of trying to > > > determine which build environment each should be built under. > > > > > > For some, like autoconf and automake, it really doesn't matter > > > because they do not contain any native executables, only scripts. > > > > > > For others, there is an obvious need for both versions, like > > > newlib and the gcc compilers. > > > > > > However, there are a number of others that I think only one > > > version of the package should be needed for both environments > > > and that the preferred environment should be MinGW. Is my > > > understanding correct so far? > > > > > > In particular, if I can get the coreutils to build under MinGW, > > > is there any need for versions of any of these programs that are > > > specific to MSys? > > > > > > > The packages that are already MSYS dependent are the packages that > > should remain MSYS dependent. In particular, coreutils. > > > Hmm. Why does something like 'true' or 'false' have to link with the > msys-1.0.dll? > It actually faster for MSYS to spawn the process when it is an MSYS application because it doesn't have to do the path conversion. There are other benefits to using the msys runtime; for example enforcing binary file i/o. It will be a lot of work that I don't have time to check for the processes to be modified to use MSVCRT.DLL. There is already a coreutils port using MSVCRT.DLL; read the caveat in the README file. Earnie |