delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/12/29/16:24:37

From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: #include <.string>
29 Dec 1998 16:24:37 -0800 :
Message-ID: <Pine.SUN.3.93.981229180117.27554A-100000.cygnus.cygwin32.developers@modi.xraylith.wisc.edu>
References: <19981229154533 DOT 34475 AT cygnus DOT com>
Mime-Version: 1.0
To: Geoffrey Noer <noer AT cygnus DOT com>
Cc: cygwin32-developers AT cygnus DOT com

On Tue, 29 Dec 1998, Geoffrey Noer wrote:

> 
> Should I do this in the main sources?  (Remove
> include/mingw32/alloc.h?)  Sounds like it...

Yes, not before you incorporate the original alloc.h into not-quite-as-
non-standard-as-alloc.h malloc.h, which is what MS did to get out of the 
mess when STL became popular. I'll send you a patch this evening or 
tomorrow. This is going into the egcs-1.1.1 release for mingw/cygb20 
out in a few days if the weather stays cold.

> When you mention "This way of running GCC is subtly broken
> unfortunately", are you referring to the Cygwin dependencies in
> libstdc++ libraries in B20?  I'm going to see if it's ok to just
> always build libstdc++ using -mno-cygwin and see what happens.  I
> think that might solve this problem without our having to go to the
> extreme of building it twice, once with Cygwin and once without it...

Here's what I mean by "subtly broken":

  - Use of -iwithprefixbefore as opposed to -iwithprefix (ie., adding
    it to the main as opposed to the second include path). Unfortunately
    using -iwithprefix doesn't work in this case. This is not a big
    deal, but it can cause weird little problems when you're testing
    new versions of system includes, which most users don't. Since I'm 
    probably the only one who gets bothered by this, so we can call this 
    a non-issue and move on.

  - No analogous mechanism to supply a linker path! This is the tricky
    one. If there was a way to supply a new prefix for the linker search
    path, then we'll be all set with -mno-cygwin and -mcygwin, etc. And,
    as a bonus, we'll never have to think about multilib'ing again ;-)

    You can of course use a -L<path/to/mingw/target/libs>, but that again
    intrudes into the user's territory, and the order of -L<path> args
    become important.

Also, note that C++ links with libstdc++.a and libm.a, so we'll need to
provide that mingw target as well. Fortunately, mignw libm.a is just an
empty/dummy archive.

Regards,
Mumit


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019