From: <dan...@ya...> - 2002-01-08 22:54:22
|
Earnie, So far I haven't played with msys, but have concentrated on getting GCC3.1 useable for mingw on a build system that I know about. It seems to be fairly stable. I hope to have some time to start with msys and then see how it works with gcc 3.1 build. Some naive questions: 1) Is the plan to release a GCC 3.1/binutils that is dependent on msys or is the plan to release a GCC 3.1/binutils that is dependent only on msvcrt.dll. Or both. 2) If I understand correctly, dependency on msys allows, among other things, a gcc/binutils that understands cygwin-style symlinks. Is that correct? 3) Has anyone "make bootstrap" "make check" GCC 3.1 or (2.95.3 for that matter) with msys? Danny http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own! |
From: Earnie B. <ear...@ya...> - 2002-01-09 15:10:37
|
Danny Smith wrote: > > > Earnie, > > So far I haven't played with msys, but have concentrated on getting GCC3.1 > useable for mingw on a build system that I know about. It seems to be > fairly stable. I hope to have some time to start with msys and then see > how it works with gcc 3.1 build. > > Some naive questions: > > 1) Is the plan to release a GCC 3.1/binutils that is dependent on msys or > is the plan to release a GCC 3.1/binutils that is dependent only on > msvcrt.dll. Or both. > Only on MSVCRT.DLL > 2) If I understand correctly, dependency on msys allows, among other > things, a gcc/binutils that understands cygwin-style symlinks. Is that > correct? > That would be correct, but I plan to rework the conversion code so that a symlink passed as an argument would be translated before the program sees it. I'm planning this for version 1.0.4, I hope to upload version 1.0.3 today which incorporates the changes I did just before the holidays. I plan for version 1.0.5 to handle the environment variable conversion. > 3) Has anyone "make bootstrap" "make check" GCC 3.1 or (2.95.3 for that > matter) with msys? > I bastardized the current Cygwin versions for MSYS. I released those with version 1.0.1 but I've removed that version from the download page as of yesterday EST. However, as you well know they are still available on the ftp server. I want MSYS to only be used as a minimal POSIX and Bourne system for native MinGW users, not a replacement for Cygwin for those interested in a more full bodied POSIX system. I may eventually distribute an unadvertised MSYS-developer release which will contain the necessary headers, runtime and a MinGW hosted cross for MSYS gcc and binutils but not before version 1.1.0. MY version 1.0.4 will have MINGW32 as the default system returned by uname. Currently you must set the environment variable MSYSTEM=MINGW32 to get that and then only during dll initialization can it be changed so you must exit all MSYS processes to change it. One of the more important points for MSYS is that only msys-1.0.dll dependent executables go to the /bin, /sbin or /usr/bin directory. Those directories are flagged to be msys-1.0.dll dependent and the translation doesn't occur. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <dan...@ya...> - 2002-01-09 20:20:26
|
--- Earnie Boyd <ear...@ya...> wrote: > Danny Smith wrote: > > > > > > > > 1) Is the plan to release a GCC 3.1/binutils that is dependent on msys > or > > is the plan to release a GCC 3.1/binutils that is dependent only on > > msvcrt.dll. Or both. > > > > Only on MSVCRT.DLL > That simplifies things. So, theoretically, a msvcrt.dll dependent GCC3.1 or binutils built in a cygwin environennt would have same functionality as same toolset built in msys build environment? The addition of msys would.... > > 2) If I understand correctly, dependency on msys allows, among other > > things, a gcc/binutils that understands cygwin-style symlinks. > > That would be correct, but I plan to rework the conversion code so that > a symlink passed as an argument would be translated before the program > sees it. ... mean that msys-1.0.4 would add symlink functionality to *my* status quo GCC 3.1 without having to rebuild. > > 3) Has anyone "make bootstrap" "make check" GCC 3.1 or (2.95.3 for > that > > matter) with msys? > > > > I bastardized the current Cygwin versions for MSYS. I released those > with version 1.0.1 but I've removed that version from the download page > as of yesterday EST. However, as you well know they are still available > on the ftp server. > > I want MSYS to only be used as a minimal POSIX and Bourne system for > native MinGW users, not a replacement for Cygwin for those interested in > a more full bodied POSIX system. I assume that the sh.exe will have same *feature* as cygwin sh.exe that requires hack in GNU make-3.79 source. Viz: in make's w32/sub-proc.c, about line 1072: while(*p) { if (*p == '\"') { if (cygwin_mode && have_sh) { /* HAVE_CYGWIN_SHELL */ /* instead of a \", cygwin likes "" */ *(command_line_i++) = '\"'; > One of the more important points for MSYS is that only msys-1.0.dll > dependent executables go to the /bin, /sbin or /usr/bin directory. > Those directories are flagged to be msys-1.0.dll dependent and the > translation doesn't occur. > Ah, its starting to become clearer now. Thanks for the explanation. Danny > Earnie. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > http://my.yahoo.com.au - My Yahoo! - It's My Yahoo! Get your own! |
From: Earnie B. <ear...@ya...> - 2002-01-09 20:40:06
|
Danny Smith wrote: > > --- Earnie Boyd <ear...@ya...> wrote: > Danny Smith wrote: > > > > > > > > > > > > 1) Is the plan to release a GCC 3.1/binutils that is dependent on msys > > or > > > is the plan to release a GCC 3.1/binutils that is dependent only on > > > msvcrt.dll. Or both. > > > > > > > Only on MSVCRT.DLL > > > > That simplifies things. So, theoretically, a msvcrt.dll dependent GCC3.1 > or binutils built in a cygwin environennt would have same functionality as > same toolset built in msys build environment? The addition of msys > would.... > > > > 2) If I understand correctly, dependency on msys allows, among other > > > things, a gcc/binutils that understands cygwin-style symlinks. > > > > That would be correct, but I plan to rework the conversion code so that > > a symlink passed as an argument would be translated before the program > > sees it. > > ... mean that msys-1.0.4 would add symlink functionality to *my* status quo > GCC 3.1 without having to rebuild. > Yep. > > > 3) Has anyone "make bootstrap" "make check" GCC 3.1 or (2.95.3 for > > that > > > matter) with msys? > > > > > > > I bastardized the current Cygwin versions for MSYS. I released those > > with version 1.0.1 but I've removed that version from the download page > > as of yesterday EST. However, as you well know they are still available > > on the ftp server. > > > > I want MSYS to only be used as a minimal POSIX and Bourne system for > > native MinGW users, not a replacement for Cygwin for those interested in > > a more full bodied POSIX system. > > I assume that the sh.exe will have same *feature* as cygwin sh.exe that > requires hack in GNU make-3.79 source. Viz: > For the time being, yes. A fix within the MSYS routines for proper quoting would be a big plus. > in make's w32/sub-proc.c, about line 1072: > > while(*p) { > if (*p == '\"') { > if (cygwin_mode && have_sh) { /* HAVE_CYGWIN_SHELL */ > /* instead of a \", cygwin likes "" */ > *(command_line_i++) = '\"'; > Hmm... How is cygwin_mode set? Perhaps changes to set based on MSYS need to occur. > > One of the more important points for MSYS is that only msys-1.0.dll > > dependent executables go to the /bin, /sbin or /usr/bin directory. > > Those directories are flagged to be msys-1.0.dll dependent and the > > translation doesn't occur. > > > > Ah, its starting to become clearer now. > Thanks for the explanation. You're welcome, Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |