delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/08/18/02:04:26

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <3B7E0566.4040603@ece.gatech.edu>
Date: Sat, 18 Aug 2001 02:04:22 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: cygwin-developers AT cygwin DOT com
Subject: Re: libiberty fix
References: <998079721 DOT 25172 DOT ezmlm AT sources DOT redhat DOT com> <3B7DA3A6 DOT 4060801 AT ece DOT gatech DOT edu> <20010817204702 DOT C23849 AT redhat DOT com> <20010817225133 DOT A27937 AT redhat DOT com>

Christopher Faylor wrote:

 > It's not a matter of ignoring.  I was trying to fix a specific
 > problem. The problem was not "How do I get libiberty working with
 > 2.52?"  It was how do I get a specific problem fixed.
 >
 > As a scientist, I know that you understand that changing two
 > variables at once is rarely a good method for solving a problem.
 > The issue of whether configure works in 2.52 is not something that
 > really concerns me.  That's an issue that can be hashed out in the
 > gcc-patches mailing list.

Sure -- except that those using the latest autoconf could not assist you
in testing your changes -- "you must regenerate configure", but I could
not.  I note that your latest patch (the .tar.bz2 one) includes the
2.13-generated configure.  :-)

 > I suspect that you are reporting errors in building the host
 > libiberty rather than the target libiberty.

Well, that's true -- but since the host libiberty is built before the
target libiberty, and I'm self-hosting (not a linux->cygwin cross), I
figured the problem would show up again in the target libiberty anyway.

 > I was confining my efforts to the libiberty that gets built in the
 > i686-pc-cygwin target directory.
 >
 > I guess I have to worry about the higher level one, too.  Hmm.
 >
 > I hate libiberty.

<g>

 > I tried a completely different tactic with this patch.  It seems to
 > me that there is no reason to build strerror.o so the patch below 
eliminates
 >  it for cygwin builds.
 >
 > I'd appreciate it if people would try this out.

testing....well, both libiberty's build okay.  cygwin...well, the dll 
builds okay and is usable, BUT make repeatedly coredumps when 'leaving 
directory <some directory>' like 
/usr/src/cygwin/obj/i686-pc-cygwin/winsup/cinstall or ../mingw.  It also 
reports the dreaded 'Signal 11'. This is when using a runtime kernel 
from 20010815.  Reverting the runtime kernel back to "clean" 1.3.2 
allows the make to continue.

Since the dll itself builds okay, I also tried substituting the new 
20010818 kernel for the 20010815 one, and then trying to complete the 
make (finish building setup.exe, the import libs, etc).  But 'Signal 11' 
returned.

I'm pretty sure this is a kernel thing and NOT a hardware problem (the 
typical response when 'signal 11' is the reported), since I can 
eliminate the error simply by using the old 1.3.2 kernel.  But I can't 
do any more debugging tonight; I'm too tired.

On the upside: the strerror problems are gone and the dll builds & runs 
as well as the one from a few days back, so I think I *may* have 
uncovered a different and unrelated bug from whatever Chris was trying 
to fix; it looks this particular WIP is finished.  (BTW, should I submit 
the autconf-2.52 related changes to gcc-patches?)

--Chuck

- Raw text -


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