The problem with compiling w3m on cygwin has been solved by recent
posts to the cygwin list. I don't think that the problem is specific
to libtermcap.a, since w3m binaries were also crashing when I compiled
with ncurses (without libtermcap.a). The problem seems to be that in
the current cygwin, libm.a is symbolically linked to libcygwin.a.
When both are linked, the cygwin linker gets confused. The trick to
compiling with the current version of cygwin is to remove "-lm" from
the list of libraries in the makefile.
Doug
(Replying from the archive)
> Date: Sat, 12 Aug 2000 14:47:23 -0400
> From: Timothy Ball <timball@tux.org>
> Message-Id: <20000812144723.A4679@gwyn.tux.org>
> References: <20000812013611.A1288@lore.ece.utexas.edu> <20000812113628.K12639@ gwyn.tux.org> <20000812114814.A25242@lore.ece.utexas.edu>
>
> Well currently the machine that hosts w3m.org is getting more
> memory/disk space and I'm making it use a journalling fs so once it's
> back up I'll be able to stare at the source.
>
> --timball
>
> On Sat, Aug 12, 2000 at 11:48:14AM -0500, Richard Kilgore wrote:
> > Version 0.1.10. And my cygwin install is 1.1.3 I believe. I've
> > tried messing with compiling a debuggable libtermcap a little,
> > and it seems that if I remove one statement that seg faults (like
> > an if condition for which I know the answer in my test
> > environment), it seg faults somewhere else. I haven't observed
> > any corrupted memory yet, but it'd be my guess that the problem
> > is happening earlier than I see it happen.
> >
> > Before screwing with the tgetent source, it crashes as it's
> > trying to call getgid(), but as I said, I don't think that there
> > is actually a problem with getgid().
> >
> > If you can remember anything or have any suggestions for how to
> > find the problem, I'd surely be grateful. I'm afraid I've
> > reached the limits of my knowledge, at this point.
> >
> > - rick
__
Doug Kaufman
Internet: dkaufman@rahul.net
This archive was generated by hypermail 2b29 : Wed Sep 20 2000 - 20:10:44 CDT