Mail Archives: cygwin-developers/2001/08/18/02:04:26
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 -