Mail Archives: cygwin/2000/06/14/10:50:29
If I am understanding this correctly, it sounds like there is a newer
version of mingw which should be merged back into the cygwin
distribution. Either that or I should just rip out all of this mingw
stuff and let the mingw maintainers deal with the problem.
Why is it that no one has mentioned this "new version" of mingw in the
last two months? If this solves the ills of all of the -mno-cygwin
users then why are we wasting our time tracking down the problems that
people are reporting? Why are the cygwin maintainers taking heat for
being "unresponsive" if there is an actual solution available?
I don't mind making a new gcc release myself but I sure don't want to
have to be a detective, tracking down stuff that I'm not particularly
interested in. With Mumit gone is anyone interested in taking the
responsibility for this stuff? I don't see any reason for me to worry
about it if there is already solutions but no one has been proactive
enough to inform the readers of cygwin AT sourceware DOT cygnus DOT com until
now.
Probably the best solution is to forward all -mno-cygwin requests to
the the mingw mailing list where they belong.
cgf
On Wed, Jun 14, 2000 at 07:26:36AM -0700, Earnie Boyd wrote:
>IMHO, this is the correct way to support this switch.
>
>Earnie.
>--- Dale Goudey <goudey AT earthlink DOT net> wrote:
>-8<-
>> With the right specs file, 1.1.2 seems to work find for what I have tried
>> (C, C++, fortran). No warranties. The enclosed specs file is a bit of a
>> hack, and some of the hacks may break for future releases of gcc/cygwin.
>> There is no good definition/specification for the specs file that I am aware
>> of other than the source code, so I assume that the specs file is fair game
>> for reformatting with each revision of the compiler.
>>
>> I use the following mingw packages
>> gcc-2.95.2-1-msvcrt.zip
>> (use the lib/gcc-lib/i386-mingw32msvc therein by moving or copying
>> it into /usr/lib/gcc-lib to make it parallel to
>> /usr/lib/gcc-lib/i686-pc-cygwin
>> (this gives you /usr/lib/gcc-lib/i386-mingw32msvc)
>>
>> use the include/g++-3 therein by moving or copying it
>> into /usr/mingw/include (this directory must be
>> created)
>>
>> and use the files i386-mingw32msvc/include/*.h therein by moving or
>> copying them into /usr/mingw/include
>> )
>> bin-msvcrt-2000-03-27.zip
>> (unpacking under /usr, and then
>> THIS IS TRICKY:
>> from a true MSDOS shell (using command.com or cmd.com), go into
>> /usr/bin.
>> If you see a single file called mingwm10.dll move it to /bin
>> You must then also undo some damage to the file structure caused by
>> the
>> unpack by going into the /usr directory and remove the undesired bin
>> directory:
>> rd bin
>> You may now exit the MSDOS shell.
>> from a cygwin shell (like an rxvt window)
>> cp -a /usr/i386-mingw32msvc/lib/*.o /usr/i686-pc-cygwin/lib
>> )
>>
>> It works for me. 100k lines of C/C++/fortran do just fine.
>>
>> I expect that the above hacks will be unnecessary and probably broken when
>> Mumit Khan returns to the scene.
>>
>> Hope this helps.
>> Dale Goudey
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -