Re: libiberty fix

[Charles Wilson <cwilson at ece dot gatech dot edu>]

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