From: <dan...@ya...> - 2000-11-17 19:06:18
|
--- Paul Sokolovsky <pf...@us...> wrote: > Hello Danny, > > Danny Smith wrote on Friday, November 17, 2000: > > > DS> --- no...@so... wrote: > Task #21054 has been > updated. > >> > >> Project: MinGW - Minimalist GNU for Windows > >> Subproject: Release Schedule > >> Summary: Create a GCC package > >> Percent Complete: 30% > >> Status: Open > >> > >> Description: Using the current GCC-2.95.2-1 build upload a binary > and > >> source distribution to download. This will help remove the > >> dependancy on Mumit's ftp site. > >> > >> Follow-Ups: > >> > >> ------------------------------------------------------- > >> Date: 2000-Nov-16 16:11 > >> By: pfalcon > >> > >> Comment: > >> Mumit's binaries was restructured and some bugs fixed' > > DS> I've just had a look at redistro of Mumit's GCC. Problem with > DS> search-dirs which are hardcoded into binaries. Points to > DS> /i386-mingw32msvc, *not* /mingw32. Try gcc -print-search-dirs. > > I have patched them! > > install: /gcc-2.95.2/lib/gcc-lib/mingw32\2.95.2\ > programs: > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.2\;e:\mingw\bin\..\lib\gcc-li > b\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\;\gcc-2.95.2\lib\gcc-lib\mingw32\;\usr > \lib\gcc\mingw32\2.95.2\;\usr\lib\gcc\mingw32\;e:\mingw\bin\..\lib\gcc-lib\mingw > 32\2.95.2\..\..\..\..\mingw32\bin\mingw32\2.95.2\;e:\mingw\bin\..\lib\gcc-lib\mi > ngw32\2.95.2\..\..\..\..\mingw32\bin\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\ > ..\..\..\mingw32\bin\mingw32\2.95.2\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\. > .\..\..\mingw32\bin\ > libraries: > e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.2\;e:\mingw\bin\..\lib\gcc-l > ib\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\;\usr\lib\gcc\mingw32\2.95.2\;e:\ming > w\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\mingw32\2.95.2\;e:\m > ingw\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\;\gcc-2.95.2\lib\ > gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\mingw32\2.95.2\;\gcc-2.95.2\lib\g > cc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\;e:\mingw\bin\..\lib\gcc-lib\mingw > 32\2.95.2\..\..\..\mingw32\2.95.2\;e:\mingw\bin\..\lib\gcc-lib\mingw32\2.95.2\.. > \..\..\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\mingw32\2.95.2\;\gcc-2.9 > 5.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\;\lib\mingw32\2.95.2\;\lib\;\usr\lib\min > gw32\2.95.2\;\usr\lib\ > > DS> Back comes the famous "cpp: unrecognised option '-remap'" > > Please make sure that you are running its gcc. If so, please > provide full info. > My working mingw tree prefix is d:/gcc-2.95.2-1 This is what I did: unzipped new gcc into d:/gcc-200011116 installed new binutils and ld into same tree then: > PATH=d:\gcc-20001116\bin;c:\winnt\system32 > gcc --print-search-dirs install: /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc\2.95.2\ programs: d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\;\usr\lib\gcc\i386-mingw32msvc\2.95.2\;\usr\lib\gcc\i386-mingw32msvc\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\ libraries: d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\;\usr\lib\gcc\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\;\lib\i386-mingw32msvc\2.95.2\;\lib\;\usr\lib\i386-mingw32msvc\2.95.2\;\usr\lib\ > gcc -c test.c cpp: unrecognized option `-remap' cpp: installation problem, cannot exec `cpp': Invalid argument cpp: unrecognized option `-remap' ...More of same... cpp: unrecognized option `-remap' > mingw32-gcc --print-search-dirs install: /gcc-2.95.2/lib/gcc-lib/mingw32\2.95.2\ programs: d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\;\gcc-2.95.2\lib\gcc-lib\mingw32\;\usr\lib\gcc\mingw32\2.95.2\;\usr\lib\gcc\mingw32\;d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\bin\mingw32\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\bin\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\bin\mingw32\2.95.2\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\bin\ libraries: d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\;\usr\lib\gcc\mingw32\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\mingw32\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\mingw32\2.95.2\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\lib\;d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\mingw32\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\mingw32\2.95.2\;\gcc-2.95.2\lib\gcc-lib\mingw32\2.95.2\..\..\..\;\lib\mingw32\2.95.2\;\lib\;\usr\lib\mingw32\2.95.2\;\usr\lib\ > mingw32-gcc -v -c test.c Reading specs from d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\specs gcc driver version 2.95.2 19991024 (release) executing gcc version 2.95.2-20001116 d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\cpp.exe -lang-c -v -iprefix d:\gcc-20001116\bin\..\lib/gcc-lib/mingw32\2.95.2\ -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___stdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ test.c D:\TEMP\ccNcaaaa.i GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/gcc-20001116/bin/../lib/gcc-lib/mingw32/2.95.2/../../../../include d:/gcc-20001116/bin/../lib/gcc-lib/mingw32/2.95.2/include End of search list. The following default directories have been omitted from the search path: /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../include/g++-3 /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../i386-mingw32msvc/include /usr/local/i386-mingw32/include End of omitted list. test.c:1: stdio.h: No such file or directory > mingw32-gcc -v -c -I/gcc-20001116/mingw32/include test.c Reading specs from d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\specsgcc driver version 2.95.2 19991024 (release) executing gcc version 2.95.2-20001116 d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\cpp.exe -lang-c -v -I/gcc-20001116/mingw32/include -iprefix d:\gcc-20001116\bin\..\lib/gcc-lib/mingw32\2.95.2\ -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___stdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ test.c D:\TEMP\ccGdaaaa.i GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: \gcc-20001116/mingw32/include d:/gcc-20001116/bin/../lib/gcc-lib/mingw32/2.95.2/../../../../include d:/gcc-20001116/bin/../lib/gcc-lib/mingw32/2.95.2/include End of search list. The following default directories have been omitted from the search path: /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../include/g++-3 /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../i386-mingw32msvc/include /usr/local/i386-mingw32/include End of omitted list. d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\cc1.exe D:\TEMP\ccGdaaaa.i -quiet -dumpbase test.c -version -o D:\TEMP\ccchaaaa.s GNU C version 2.95.2 19991024 (release) (i386-mingw32msvc) compiled by GNU C version 2.95.2 19991024 (release). d:\gcc-20001116\bin\..\lib\gcc-lib\mingw32\2.95.2\..\..\..\..\mingw32\bin\as.exe -o test.o D:\TEMP\ccchaaaa.s The last test finally worked. Comparison of gcc binaries with original distro shoes nill differences. Are you sure you packaged the *patched* binaries into the zip? Danny _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: <dan...@ya...> - 2000-11-20 22:27:59
|
> > Here's md5sum, please check: > 3c74b8d4554f16ff6ef1e34eb9ea1d07 c++.exe > 3e12ab328b2e02d1ffc07991b2d4aafb cpp.exe > 3c74b8d4554f16ff6ef1e34eb9ea1d07 g++.exe > 6bcb0a0804e186cac4ddce8da832cfec gcc.exe > dbdc977868e0533765f9818ee4a9efd3 gcov.exe > d667b38e32775facb1b93c98b95cef96 mingw32-gcc.exe > 1ad2c949c45ab0692d6d88f950a8bdb5 protoize.exe > 99aed4f96fbdfb4bb2388e41122d17f0 unprotoize.exe > Paul, Sorry, my problem, not yours. I checked the md5sums and all but mingw32-gcc.exe failed. Hmm. Removed some hardlinks that I had been experimenting with using the WriteBackupFile API. Cleaned out my Recycle bin. Reinstalled your package. Ran the checksums again and everything passed! Ran my test script and everything worked! Sorry about the false report. > Well, but I found 'i386-mingw...' stuff in some other places, > for > example in lib/gcc-lib/mingw32/2.95.2/cpp.exe and in specs - I may > imagine > it gives you those paths. But why I have all ok ;-? Well, I will > destroy them completely. > No don't destroy. It does work. I apologise again . Danny _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: Earnie B. <ear...@ya...> - 2000-11-20 22:34:38
|
--- Paul Sokolovsky <pf...@us...> wrote: > > Well, but I found 'i386-mingw...' stuff in some other places, for > example in lib/gcc-lib/mingw32/2.95.2/cpp.exe and in specs - I may imagine > it gives you those paths. But why I have all ok ;-? Well, I will > destroy them completely. > Can we drop the 32 from mingw? Or should we consider that platform specific enough to leave it there? My preference would be to remove it and identify the 32bit vs FOObit via a specific directory when needed. E.G.: lib/gcc-lib/mingw/2.95.2/32bit/, lib/gcc-lib/mingw/2.95.2/64bit/, etc. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/ |
From: Paul S. <pf...@us...> - 2000-11-20 23:50:37
|
Hello Earnie, Earnie Boyd wrote on Tuesday, November 21, 2000: EB> --- Paul Sokolovsky <pf...@us...> wrote: >> >> Well, but I found 'i386-mingw...' stuff in some other places, for >> example in lib/gcc-lib/mingw32/2.95.2/cpp.exe and in specs - I may imagine >> it gives you those paths. But why I have all ok ;-? Well, I will >> destroy them completely. >> EB> Can we drop the 32 from mingw? We have dropped it from descriptive name, yes. EB> Or should we consider that platform specific EB> enough to leave it there? But here 'mingw32' is the formal target identifier, and *settled* (not by us) identifier. EB> My preference would be to remove it and identify the 32bit vs FOObit via a EB> specific directory when needed. E.G.: lib/gcc-lib/mingw/2.95.2/32bit/, EB> lib/gcc-lib/mingw/2.95.2/64bit/, etc. Earnie, believe me, such things are outside of our control. Directory structure of developmental tools specified by GNU standards, not us. We could pick around it, but what for? The same applies to top-level 'mingw32' ('i386-mingw32msvc' before) directory with binutils and gcc - it's there not because it's canadian cross or whatever (if I didn't tell, I applied your recommdations for target/host configure switches, it doesn't help), but because it *should* be there (yes, to allow for multiple targets with the same gcc binaries, and yes, it is unalienable gcc feature, and it is needed even with mingw, and we should not take additional effort just to get rid of it). EB> Cheers, EB> ===== EB> Earnie Boyd EB> mailto:ear...@ya... -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: <dan...@ya...> - 2000-11-21 00:20:44
|
--- Earnie Boyd <ear...@ya...> wrote: > --- Paul Sokolovsky <pf...@us...> wrote: > > > > Well, but I found 'i386-mingw...' stuff in some other places, > for > > example in lib/gcc-lib/mingw32/2.95.2/cpp.exe and in specs - I may > imagine > > it gives you those paths. But why I have all ok ;-? Well, I will > > destroy them completely. > > > > Can we drop the 32 from mingw? Or should we consider that platform > specific > enough to leave it there? > > My preference would be to remove it and identify the 32bit vs FOObit > via a > specific directory when needed. E.G.: > lib/gcc-lib/mingw/2.95.2/32bit/, > lib/gcc-lib/mingw/2.95.2/64bit/, etc. > Are there any precedents for that in other GCC targets? How would that affect existing configure scripts? Regards Danny _____________________________________________________________________________ http://clubs.yahoo.com.au - Yahoo! Clubs - Join a club or build your own! |
From: Earnie B. <ear...@ya...> - 2000-11-21 01:08:05
|
--- Paul Sokolovsky <pf...@us...> wrote: > Hello Earnie, > > > EB> Can we drop the 32 from mingw? > > We have dropped it from descriptive name, yes. > Which is the reason I'm suggesting it here. > EB> Or should we consider that platform specific > EB> enough to leave it there? > > But here 'mingw32' is the formal target identifier, and *settled* > (not by us) identifier. > My guess is that it was a Mumit patch. The mingw32 is controlled by config.guess and config.sub which are scripts that can be patched. Nothing magical and nothing really set in stone. Submitting a patch to aut...@gn... would be all that would be necessary. > EB> My preference would be to remove it and identify the 32bit vs FOObit via > a > EB> specific directory when needed. E.G.: lib/gcc-lib/mingw/2.95.2/32bit/, > EB> lib/gcc-lib/mingw/2.95.2/64bit/, etc. > > Earnie, believe me, such things are outside of our control. > Directory structure of developmental tools specified by GNU standards, > not us. Ah, yes, the standard. The standard is a theoretical document that should be followed but is itself patchable if arguments prove for the better. > We could pick around it, but what for? Correct, sigh. Why waste our energy for something this minimal. > The same applies to > top-level 'mingw32' ('i386-mingw32msvc' before) directory with > binutils and gcc - it's there not because it's canadian cross or > whatever (if I didn't tell, I applied your recommdations for > target/host configure switches, it doesn't help), but because > it *should* be there (yes, to allow for multiple targets with the same > gcc binaries, and yes, it is unalienable gcc feature, and it is > needed even with mingw, and we should not take additional effort just > to get rid of it). > I figured this out on my own. However, I believe that we can mv the files to /mingw/lib, /mingw/include and /mingw/bin from the /mingw/mingw32/lib, etc. when creating a distribution. Chris has created a script he runs to create the Cygwin distribution, we could likewise do the same. So, if we get config.guess and config.sub patched; then, configure --host=mingw would be possible. But, not worth it in the long run. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
From: Paul S. <pf...@us...> - 2000-11-21 01:55:49
|
Hello Earnie, Earnie Boyd wrote on Tuesday, November 21, 2000: EB> My guess is that it was a Mumit patch. The mingw32 is controlled by EB> config.guess and config.sub which are scripts that can be patched. Nothing EB> magical and nothing really set in stone. Submitting a patch to EB> aut...@gn... would be all that would be necessary. Yep ;-) But you forget distributions which already have those scripts with current name. It will take time (lo-o-o-ng time ;-) ) to have all stuff update. EB> Correct, sigh. Why waste our energy for something this minimal. Good. Let's better consider importing mingw runtime, finally. Do you have time for this? If no, please create task and assign it to me. EB> Cheers, EB> ===== EB> Earnie Boyd EB> mailto:ear...@ya... -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Earnie B. <ear...@ya...> - 2000-11-21 01:11:18
|
--- Danny Smith <dan...@ya...> wrote: > > specific directory when needed. E.G.: > > lib/gcc-lib/mingw/2.95.2/32bit/, > > lib/gcc-lib/mingw/2.95.2/64bit/, etc. > > > > Are there any precedents for that in other GCC targets? Don't have a clue. As already pointed out by Paul, it's not worth doing for the amount of work involved with getting it done officially. > How would that affect existing configure scripts? > Just, GCC would be affected and I don't know what ramifications there would be. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
From: Earnie B. <ear...@ya...> - 2000-11-21 03:19:19
|
--- Paul Sokolovsky <pf...@us...> wrote: > > Good. Let's better consider importing mingw runtime, finally. Do > you have time for this? If no, please create task and assign it to me. > Late tomorrow. If you need it before then you can pick up the mingw package from cygwin/latest/mingw. Cheers, ===== Earnie Boyd mailto:ear...@ya... --- <http://earniesystems.safeshopper.com> --- --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- --- Minimalist GNU for Windows <http://www.mingw.org/> --- __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ |
From: Paul G. <pga...@te...> - 2000-11-22 00:18:38
|
Hi folks, On 20 Nov 2000, at 14:34, the Illustrious Earnie Boyd wrote: > --- Paul Sokolovsky <pf...@us...> wrote: > > > > Well, but I found 'i386-mingw...' stuff in some other > > places, for > > example in lib/gcc-lib/mingw32/2.95.2/cpp.exe and in specs - I > > may imagine it gives you those paths. But why I have all ok ;-? > > Well, I will destroy them completely. > > > > Can we drop the 32 from mingw? Or should we consider that > platform specific enough to leave it there? I say drop it. No sense in maintaining it since the expectation was originally to be open to 64bit as well as 32bit mingw. A main reason for the name mingw, as opposed to mingw32 was due to Mumits desire to do just what I outlined above. In fact there are already headers included with mingw that are set up to handle 64bit stuff. > > My preference would be to remove it and identify the 32bit vs > FOObit via a specific directory when needed. E.G.: > lib/gcc-lib/mingw/2.95.2/32bit/, lib/gcc-lib/mingw/2.95.2/64bit/, I agree. Peace, Paul G. > etc. > > Cheers, > > ===== > Earnie Boyd > mailto:ear...@ya... > > --- <http://earniesystems.safeshopper.com> --- > --- Cygwin: POSIX on Windows <http://gw32.freeyellow.com/> --- > --- Minimalist GNU for Windows <http://www.mingw.org/> --- > > __________________________________________________ > Do You Yahoo!? > Yahoo! Calendar - Get organized for the holidays! > http://calendar.yahoo.com/ > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > http://lists.sourceforge.net/mailman/listinfo/mingw-dvlpr > Nothing real can be threatened. Nothing unreal exists. |
From: Paul S. <pf...@us...> - 2000-11-20 21:34:24
|
Hello Danny, Danny Smith wrote on Friday, November 17, 2000: >> Please make sure that you are running its gcc. If so, please >> provide full info. >> DS> My working mingw tree prefix is d:/gcc-2.95.2-1 DS> This is what I did: DS> unzipped new gcc into d:/gcc-200011116 DS> installed new binutils and ld into same tree DS> then: >> PATH=d:\gcc-20001116\bin;c:\winnt\system32 >> gcc --print-search-dirs DS> install: /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc\2.95.2\ DS> programs: DS> d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\;\usr\lib\gcc\i386-mingw32msvc\2.95.2\;\usr\lib\gcc\i386-mingw32msvc\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\bin\ DS> libraries: DS> d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\;\usr\lib\gcc\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\lib\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\i386-mingw32msvc\2.95.2\;d:\gcc-20001116\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\i386-mingw32msvc\2.95.2\;\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\;\lib\i386-mingw32msvc\2.95.2\;\lib\;\usr\lib\i386-mingw32msvc\2.95.2\;\usr\lib\ [] DS> Comparison of gcc binaries with original distro shoes nill differences. DS> Are you sure you packaged the *patched* binaries into the zip? Mystic! I uploaded (once!) package to my server, and from there - directly to SF. Package on my server has differences with original. Morever, no file from bin/ (except un/protoize) has 'i386-mingw...' anymore! Here's md5sum, please check: 3c74b8d4554f16ff6ef1e34eb9ea1d07 c++.exe 3e12ab328b2e02d1ffc07991b2d4aafb cpp.exe 3c74b8d4554f16ff6ef1e34eb9ea1d07 g++.exe 6bcb0a0804e186cac4ddce8da832cfec gcc.exe dbdc977868e0533765f9818ee4a9efd3 gcov.exe d667b38e32775facb1b93c98b95cef96 mingw32-gcc.exe 1ad2c949c45ab0692d6d88f950a8bdb5 protoize.exe 99aed4f96fbdfb4bb2388e41122d17f0 unprotoize.exe Well, but I found 'i386-mingw...' stuff in some other places, for example in lib/gcc-lib/mingw32/2.95.2/cpp.exe and in specs - I may imagine it gives you those paths. But why I have all ok ;-? Well, I will destroy them completely. DS> Danny -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |