Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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. > 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 ' 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