Termcap saga

Termcap saga

[Peter Stephenson]

After updating and reconfiguring from scratch on cygwin with
--disable-dynamic I now get

Modules/termcap.o(.text+0xad): undefined reference to `_imp__tgetnum'
Modules/termcap.o(.text+0xf1): undefined reference to `_imp__tgetflag'
Modules/termcap.o(.text+0x134): undefined reference to `_imp__tgetstr'
Modules/termcap.o(.text+0x27c): undefined reference to `_imp__tputs'
Modules/termcap.o(.text+0x2ff): undefined reference to `_imp__tgoto'
Modules/termcap.o(.text+0x30d): undefined reference to `_imp__tputs'
Modules/termcap.o(.text+0x594): undefined reference to `_imp__tgetnum'
Modules/termcap.o(.text+0x5e1): undefined reference to `_imp__tgetflag'
Modules/termcap.o(.text+0x654): undefined reference to `_imp__tgetstr'
Modules/termcap.o(.text+0xd0f): undefined reference to `_imp__tgetflag'
Modules/termcap.o(.text+0xdb7): undefined reference to `_imp__tgetnum'
Modules/termcap.o(.text+0xe42): undefined reference to `_imp__tgetstr'

What do I do about this?  The link line is

gcc -g   -o zsh.exe main.o zsh.res.o `cat stamp-modobjs`   -ltermcap -lm -L/g/bc01/bc01/devHost/HostStack -lzframe -lc

(the extra library I added is irrelevant here).  Somehow the termcap module
seems to think it has to import the symbols, which in this case it doesn't.
config.modules has

name=zsh/termcap modfile=Src/Modules/termcap.mdd link=static auto=yes load=yes
name=zsh/terminfo modfile=Src/Modules/terminfo.mdd link=static auto=yes load=yes

I haven't been following all this closely enough to see where the problem
might be.  Should terminfo really be being linked if curses isn't in use?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Termcap saga

[Peter Stephenson]

> After updating and reconfiguring from scratch on cygwin with
> --disable-dynamic I now get
> 
> Modules/termcap.o(.text+0xad): undefined reference to `_imp__tgetnum'

My latest guess: it's including term.h, which is ncurses based, which
defines tgetnum etc. to be imported from the curses library instead of
directly linked from termcap.  However, it's finding tget* in -ltermcap and
not linking curses.  This is pretty similar to the position on
SunOS 5.6 in that termcap is static but curses is dynamic, but
unfortunately here the headers are different for imported symbols.

What's supposed to happen after the last set of changes?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Termcap saga

[Bart Schaefer]

On May 1,  1:58pm, Peter Stephenson wrote:
}
} What's supposed to happen after the last set of changes?

The trouble is that configure's -lcurses vs. -ltermcap decision is based
on linking to tgetent, but term{cap,info}.c's decision of which headers
to included is based only on whether those headers are present.  So it
includes headers it doesn't need, and (for the same reason that Andrej
was having trouble with the stat module -- the Cygwin folks are getting
overzealous with `const') it ends up declaring global variables it won't
need.

Since nobody has howled about 14177 changing the configure messages, I'll
commit it and then look at moving the checks for curses.h and term.h into
the section for --with-curses-terminfo so they'll be checked for only if
they're going to be needed.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Termcap saga

[F. G. Marx]

I made clean, Util/preconfig'ed, and configure'd --with-curses-terminfo,
and -ltermcap, which had been being included along with -l(n)curses for a
while (linux), was dropped from the link line.

Test ./C02cond.ztst failed: bad status 1, expected 0 from:
  [[ -r zerolength && ! -r unmodish ]]

was the only fail.

Bart Schaefer writes:
 > On May 1,  1:58pm, Peter Stephenson wrote:
 > }
 > } What's supposed to happen after the last set of changes?
 > 
 > The trouble is that configure's -lcurses vs. -ltermcap decision is based
 > on linking to tgetent, but term{cap,info}.c's decision of which headers
 > to included is based only on whether those headers are present.  So it
 > includes headers it doesn't need, and (for the same reason that Andrej
 > was having trouble with the stat module -- the Cygwin folks are getting
 > overzealous with `const') it ends up declaring global variables it won't
 > need.
 > 
 > Since nobody has howled about 14177 changing the configure messages, I'll
 > commit it and then look at moving the checks for curses.h and term.h into
 > the section for --with-curses-terminfo so they'll be checked for only if
 > they're going to be needed.
 > 
 > -- 
 > Bart Schaefer                                 Brass Lantern Enterprises
 > http://www.well.com/user/barts              http://www.brasslantern.com
 > 
 > Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   
 > 

Re: Termcap saga

[Bart Schaefer]

On May 2,  1:22am, F. G. Marx wrote:
} 
} I made clean, Util/preconfig'ed, and configure'd --with-curses-terminfo,
} and -ltermcap, which had been being included along with -l(n)curses for a
} while (linux), was dropped from the link line.

That's as expected when libcurses supplies both tigetstr() and tgetent().

} Test ./C02cond.ztst failed: bad status 1, expected 0 from:
}   [[ -r zerolength && ! -r unmodish ]]

You weren't by any chance running "make check" as root, were you?  Even
`chmod 0' can't prevent root from reading a file.


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

_use_lo is still being refered to

[F. G. Marx]

I wrote a while ago about the old Completion/Unix/_use_lo function being
referenced at _normal:100.  I've consistently rm'ed my old zcompdump before
starting a cvs-updated zsh.  I've fgrep'ed my entire source tree, and find
no references to it, no old *.zwc files, nothing.

Any posibility it's in shared memory (I run three vt's + X(-terms)) (and I
test (and update zcompdump) in one vt while the old version runs in the
others).

Thanks,

/f

Re: _use_lo is still being refered to

[Bart Schaefer]

On May 2,  1:31am, F. G. Marx wrote:
} 
} Any posibility it's in shared memory (I run three vt's + X(-terms)) (and I
} test (and update zcompdump) in one vt while the old version runs in the
} others).

No, it can't be shared memory.  Have you tried `ls -l $^fpath/_use_lo' ?

If all else fails, put `exec 2> /tmp/xtrace; set -x' very early in your
init files, and then look through the xtrace output for _use_lo.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: _use_lo is still being refered to

[F. G. Marx]

Thank you.  What an idiot.  I discovered it ... in .zshrc, after going
back to my study of the new completion system, and finding a reference
to "compdef -P _gnu_generic '*'".  I'd been over that same line when
it read "compdef -P _use_lo '*'", and installed it....


Shared memory *is* used in the context of *.zwc files, is that not
correct?


Thanks,


/f


On Wed, 2 May 2001 07:57:17 +0000, "Bart Schaefer" <schaefer@candle.brasslantern.com> wrote:
>
>On May 2,  1:31am, F. G. Marx wrote:
>} 
>} Any posibility it's in shared memory (I run three vt's + X(-terms)) (and I
>} test (and update zcompdump) in one vt while the old version runs in the
>} others).
>
>No, it can't be shared memory.  Have you tried `ls -l $^fpath/_use_lo' ?
>
>If all else fails, put `exec 2> /tmp/xtrace; set -x' very early in your
>init files, and then look through the xtrace output for _use_lo.
>
>-- 
>Bart Schaefer                                 Brass Lantern Enterprises
>http://www.well.com/user/barts              http://www.brasslantern.com
>
>Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   
>
>
------------------------------------------------
f.g.marx		<fmarx@crosswinds.net>

Re: _use_lo is still being refered to

[Bart Schaefer]

On May 2, 11:55am, F. G. Marx wrote:
}
} Shared memory *is* used in the context of *.zwc files, is that not
} correct?

The .zwc files are loaded by memory-mapping them when that's possible,
so effectively the answer is "yes," though I don't think they'd continue
to be shared if written to.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Termcap saga

[Andrej Borsenkow]

On Tue, 1 May 2001, Peter Stephenson wrote:

> After updating and reconfiguring from scratch on cygwin with
> --disable-dynamic I now get
>
> Modules/termcap.o(.text+0xad): undefined reference to `_imp__tgetnum'
> Modules/termcap.o(.text+0xf1): undefined reference to `_imp__tgetflag'
> Modules/termcap.o(.text+0x134): undefined reference to `_imp__tgetstr'
> Modules/termcap.o(.text+0x27c): undefined reference to `_imp__tputs'
> Modules/termcap.o(.text+0x2ff): undefined reference to `_imp__tgoto'
> Modules/termcap.o(.text+0x30d): undefined reference to `_imp__tputs'
> Modules/termcap.o(.text+0x594): undefined reference to `_imp__tgetnum'
> Modules/termcap.o(.text+0x5e1): undefined reference to `_imp__tgetflag'
> Modules/termcap.o(.text+0x654): undefined reference to `_imp__tgetstr'
> Modules/termcap.o(.text+0xd0f): undefined reference to `_imp__tgetflag'
> Modules/termcap.o(.text+0xdb7): undefined reference to `_imp__tgetnum'
> Modules/termcap.o(.text+0xe42): undefined reference to `_imp__tgetstr'
>
> What do I do about this?  The link line is
>
> gcc -g   -o zsh.exe main.o zsh.res.o `cat stamp-modobjs`   -ltermcap -lm -L/g/bc01/bc01/devHost/HostStack -lzframe -lc
>
> (the extra library I added is irrelevant here).  Somehow the termcap module
> seems to think it has to import the symbols, which in this case it doesn't.

Well, on Monday I recompiled on cygwin, but without --disable-synamic. The
above symbols look O.K. to me - they belong to termcap (IIRC terminfo
versions are called tigetnum etc). What version of Cygwin and utilities
are you using?


> config.modules has
>
> name=zsh/termcap modfile=Src/Modules/termcap.mdd link=static auto=yes load=yes
> name=zsh/terminfo modfile=Src/Modules/terminfo.mdd link=static auto=yes load=yes
>

Unless you forced ncurses, it should not link terminfo. It did not in my
case (yesterday). But I did not do clean reconfigure - just make in build
directory (it did run config.status --recheck). I will be able to check on
Thursday.

> I haven't been following all this closely enough to see where the problem
> might be.  Should terminfo really be being linked if curses isn't in use?
>

No. I repeat, it did not (until recently) for me. But the above does not
look like terminfo stuff.

-andrej

Re: Termcap saga

[Andrej Borsenkow]

On Tue, 1 May 2001, Andrej Borsenkow wrote:

> On Tue, 1 May 2001, Peter Stephenson wrote:
>
> > After updating and reconfiguring from scratch on cygwin with
> > --disable-dynamic I now get
> >
> > Modules/termcap.o(.text+0xad): undefined reference to `_imp__tgetnum'
...
> >
> > What do I do about this?  The link line is
> >
> > gcc -g   -o zsh.exe main.o zsh.res.o `cat stamp-modobjs`   -ltermcap -lm -L/g/bc01/bc01/devHost/HostStack -lzframe -lc
> >
> > (the extra library I added is irrelevant here).  Somehow the termcap module
> > seems to think it has to import the symbols, which in this case it doesn't.
>
> Well, on Monday I recompiled on cygwin, but without --disable-synamic. The
> above symbols look O.K. to me - they belong to termcap (IIRC terminfo
> versions are called tigetnum etc). What version of Cygwin and utilities
> are you using?
>

It looks, like zsh picks up ncurses defitions but tries to link against
termcap. There is no termcap DLL under cygwin, so the above comes from
ncurses.

There was a short period of time when installing ncurses would overwrite
termcap.h with its own header; it is fixed now but if you happen to catch
this old version, you have to reinstall termcap to get original header.

There is no term.h under Cygwin so it looks like the only possibility.

-andrej

Re: Termcap saga

[Peter Stephenson]

> There was a short period of time when installing ncurses would overwrite
> termcap.h with its own header; it is fixed now but if you happen to catch
> this old version, you have to reinstall termcap to get original header.
> 
> There is no term.h under Cygwin so it looks like the only possibility.

termcap.h looks OK, but there is a term.h in my case which smells strongly
of ncurses.  It could be that's gone since the last time I installed
cygwin.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

PATCH: Re: Termcap saga

[Bart Schaefer]

On May 2, 10:38am, Peter Stephenson wrote:
} Subject: Re: Termcap saga
}
} > There was a short period of time when installing ncurses would overwrite
} > termcap.h with its own header; it is fixed now but if you happen to catch
} > this old version, you have to reinstall termcap to get original header.
} > 
} > There is no term.h under Cygwin so it looks like the only possibility.
} 
} termcap.h looks OK, but there is a term.h in my case which smells strongly
} of ncurses.  It could be that's gone since the last time I installed
} cygwin.

See if this doesn't fix you up.  It also repairs a bug that I introduced
when reshuffling the order of some of the --enable option checks.

Index: configure.in
===================================================================
--- configure.in	2001/05/02 15:04:40	1.6
+++ configure.in	2001/05/02 15:48:17
@@ -425,7 +425,6 @@
 
 [if test x$enableval = xyes; then
 
-  if test $ac_cv_header_linux_tasks_h = yes; then
    AC_EGREP_CPP(yes,
    [#include <linux/tasks.h>
     #ifdef MAX_TASKS_PER_USER
@@ -433,7 +432,6 @@
     #endif
    ],
    maxj=max)
-  fi
 
    if test x$maxj = xmax; then
     AC_DEFINE(MAXJOB, MAX_TASKS_PER_USER)
@@ -478,7 +476,7 @@
 		 limits.h fcntl.h libc.h sys/utsname.h sys/resource.h \
 		 locale.h errno.h stdlib.h unistd.h sys/capability.h \
 		 utmp.h utmpx.h sys/types.h pwd.h grp.h poll.h sys/mman.h \
-		 linux/tasks.h netinet/in_systm.h curses.h term.h)
+		 netinet/in_systm.h)
 if test $dynamic = yes; then
   AC_CHECK_HEADERS(dlfcn.h)
   AC_CHECK_HEADERS(dl.h)
@@ -562,6 +560,11 @@
 esac])dnl
 
 AC_SEARCH_LIBS(tgetent, [$termcap_curses_order])
+case "$LIBS" in
+*curses*)
+AC_CHECK_HEADERS(curses.h term.h)
+if test x$ac_cv_header_term_h = xyes; then
+
 AC_MSG_CHECKING(if term.h needs curses.h)
 AC_TRY_COMPILE([#include <term.h>], [char **test = boolcodes;], boolcodes_with_only_term_h=yes,
 boolcodes_with_only_term_h=no)
@@ -612,6 +615,9 @@
 #include <term.h>], [char **test = strnames; printf(*test);],
 AC_DEFINE(HAVE_STRNAMES) strnames=yes, strnames=no)
 AC_MSG_RESULT($strnames)
+
+fi;;
+esac
 
 dnl Some systems (Solaris 2.x, Linux Redhat 5.x) require
 dnl libnsl (Network Services Library) to find yp_all

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Re: Termcap saga

[Peter Stephenson]

> See if this doesn't fix you up.  It also repairs a bug that I introduced
> when reshuffling the order of some of the --enable option checks.

Works a treat (unless the treat is rice pudding, in which case it works a
whole lot better).  Thanks.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************