cscope

Bugs item #454741, was opened at 2001-08-23 15:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ming Fan (xmfanx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmenation Fault on Solaris X86 (01/01)

Initial Comment:
cscope(v15.3, same as in v15.1) compiled on Solaris 8 
(x86, 01/01 release) and crashed with segmentation 
fault upon parsing source files.

Sounds like the native _curses_ library doesn't work 
well with cscope.

cscope needs to compiling with _ncurses_ library on 
this platform. But there's a bug preventing linking 
with ncurses library:
 
you might configure cscope compiling with ncurses 
library through:
 $ ./configure --with-ncurses

The configure(1) then detectes ncurses library and 
generates Makefiles. But the generated Makefiles are 
hardcoded with:
   -lcurses

--

After correct this problem. cscope(1) works fine.


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:30

Message:
Logged In: YES 
user_id=27517

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?
If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

Anyway: how did you conclude that the curses library was the
root of the original crash? Parsing itself doesn't involve
any calls to curses. Only the progress bar does --- was that
were your segfault came from? Could you show a backtrace?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Bugs item #454741, was opened at 2001-08-23 15:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ming Fan (xmfanx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmenation Fault on Solaris X86 (01/01)

Initial Comment:
cscope(v15.3, same as in v15.1) compiled on Solaris 8 
(x86, 01/01 release) and crashed with segmentation 
fault upon parsing source files.

Sounds like the native _curses_ library doesn't work 
well with cscope.

cscope needs to compiling with _ncurses_ library on 
this platform. But there's a bug preventing linking 
with ncurses library:
 
you might configure cscope compiling with ncurses 
library through:
 $ ./configure --with-ncurses

The configure(1) then detectes ncurses library and 
generates Makefiles. But the generated Makefiles are 
hardcoded with:
   -lcurses

--

After correct this problem. cscope(1) works fine.


----------------------------------------------------------------------

>Comment By: Ming Fan (xmfanx)
Date: 2001-08-24 09:37

Message:
Logged In: YES 
user_id=306237

Please check my comments below:

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?

xmfanx> yeah, I'm sure each time I did _make distclean_.

If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

xmfanx> right, but the default build on Solaris yield 
unuseable executable cscope, I'm afraid it's a severe bug. 
As I remember I had the same experience on Solaris (sparc) 
platform. And I have to keep an ancient copy of cscope from 
SUNWspro package.

Anyway: how did you conclude that the curses library was the
root of the original crash?
xmfanx> I assume cscope is stable and has being used alot 
on different platform, my cscope on linux (x86 and PPC) 
works fine, which is built by following the default steps 
(./configure; make; make install). Thus I suspect it's 
library problem on Solaris.

Parsing itself doesn't involve any calls to curses. Only 
the progress bar does --- was that
were your segfault came from?

xmfanx> agreed. So i did something silly. First I tryed to 
use flex instead of default *lex* (make 
distclean; ./configiure --with-flex;
make; make install), then try it on a relatively big 
project (about 4000 source files), failed again.

xmfanx> Then i tried the same to use bison instead of 
default *yacc*, failed again. 

xmfanx> <<<Later I realize cscope 15.3 is actually using 
flex and bison by default. ;) >>>

xmfanx> I thought it might not be a parsing problem. 

xmfanx> Actually during parsing, the curses screen is 
already init'ed, so I tried to use Solaris' native curses 
library instead ncurses, I commented out -DRENAMED_NCURSES. 
At the same time I noticed CURSES_LIBS is defined as -
lcurses though it's conifgured to use ncurses library. It 
failed again.

xmfanx> I fall back to use ncurses library and correct 
CURSES_LIBS to be defined as -lncurses. It works well.

Could you show a backtrace? 
xmfanx> Here you are. 
copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
Core was generated by `cscope'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libcurses.so.1...done.
Loaded symbols for /usr/lib/libcurses.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
#0  0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
#1  0xdfb8723c in w32addch () from /usr/lib/libcurses.so.1
#2  0xdfb7bedf in waddch () from /usr/lib/libcurses.so.1
#3  0x805bf11 in progress (what=0x806e53a "Building symbol 
database", 
    current=80, max=3799) at display.c:561
#4  0x80621d2 in build () at main.c:982
#5  0x8061435 in main (argc=0, argv=0x8047c08) at main.c:563
(gdb) 

--
BTW, I think cscope might have the same problem on all 
Solaris releases. Please check.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:30

Message:
Logged In: YES 
user_id=27517

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?
If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

Anyway: how did you conclude that the curses library was the
root of the original crash? Parsing itself doesn't involve
any calls to curses. Only the progress bar does --- was that
were your segfault came from? Could you show a backtrace?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Bugs item #454741, was opened at 2001-08-23 15:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ming Fan (xmfanx)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: Segmenation Fault on Solaris X86 (01/01)

Initial Comment:
cscope(v15.3, same as in v15.1) compiled on Solaris 8 
(x86, 01/01 release) and crashed with segmentation 
fault upon parsing source files.

Sounds like the native _curses_ library doesn't work 
well with cscope.

cscope needs to compiling with _ncurses_ library on 
this platform. But there's a bug preventing linking 
with ncurses library:
 
you might configure cscope compiling with ncurses 
library through:
 $ ./configure --with-ncurses

The configure(1) then detectes ncurses library and 
generates Makefiles. But the generated Makefiles are 
hardcoded with:
   -lcurses

--

After correct this problem. cscope(1) works fine.


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 09:15

Message:
Logged In: YES 
user_id=27517

OK, that backtrace essentially proves that the problem is,
indeed, with the curses library you use. I'm not quite sure
I understand how you built your non-ncurses version of the
executable, though. Could you please show the config.h and
config.cache files for that case (mail to me, or Upload into
this bug report form).

----------------------------------------------------------------------

Comment By: Ming Fan (xmfanx)
Date: 2001-08-24 09:37

Message:
Logged In: YES 
user_id=306237

Please check my comments below:

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?

xmfanx> yeah, I'm sure each time I did _make distclean_.

If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

xmfanx> right, but the default build on Solaris yield 
unuseable executable cscope, I'm afraid it's a severe bug. 
As I remember I had the same experience on Solaris (sparc) 
platform. And I have to keep an ancient copy of cscope from 
SUNWspro package.

Anyway: how did you conclude that the curses library was the
root of the original crash?
xmfanx> I assume cscope is stable and has being used alot 
on different platform, my cscope on linux (x86 and PPC) 
works fine, which is built by following the default steps 
(./configure; make; make install). Thus I suspect it's 
library problem on Solaris.

Parsing itself doesn't involve any calls to curses. Only 
the progress bar does --- was that
were your segfault came from?

xmfanx> agreed. So i did something silly. First I tryed to 
use flex instead of default *lex* (make 
distclean; ./configiure --with-flex;
make; make install), then try it on a relatively big 
project (about 4000 source files), failed again.

xmfanx> Then i tried the same to use bison instead of 
default *yacc*, failed again. 

xmfanx> <<<Later I realize cscope 15.3 is actually using 
flex and bison by default. ;) >>>

xmfanx> I thought it might not be a parsing problem. 

xmfanx> Actually during parsing, the curses screen is 
already init'ed, so I tried to use Solaris' native curses 
library instead ncurses, I commented out -DRENAMED_NCURSES. 
At the same time I noticed CURSES_LIBS is defined as -
lcurses though it's conifgured to use ncurses library. It 
failed again.

xmfanx> I fall back to use ncurses library and correct 
CURSES_LIBS to be defined as -lncurses. It works well.

Could you show a backtrace? 
xmfanx> Here you are. 
copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
Core was generated by `cscope'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libcurses.so.1...done.
Loaded symbols for /usr/lib/libcurses.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
#0  0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
#1  0xdfb8723c in w32addch () from /usr/lib/libcurses.so.1
#2  0xdfb7bedf in waddch () from /usr/lib/libcurses.so.1
#3  0x805bf11 in progress (what=0x806e53a "Building symbol 
database", 
    current=80, max=3799) at display.c:561
#4  0x80621d2 in build () at main.c:982
#5  0x8061435 in main (argc=0, argv=0x8047c08) at main.c:563
(gdb) 

--
BTW, I think cscope might have the same problem on all 
Solaris releases. Please check.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:30

Message:
Logged In: YES 
user_id=27517

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?
If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

Anyway: how did you conclude that the curses library was the
root of the original crash? Parsing itself doesn't involve
any calls to curses. Only the progress bar does --- was that
were your segfault came from? Could you show a backtrace?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Bugs item #454741, was opened at 2001-08-23 15:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Category: None
Group: None
Status: Open
>Resolution: Postponed
Priority: 5
Submitted By: Ming Fan (xmfanx)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: Segmenation Fault on Solaris X86 (01/01)

Initial Comment:
cscope(v15.3, same as in v15.1) compiled on Solaris 8 
(x86, 01/01 release) and crashed with segmentation 
fault upon parsing source files.

Sounds like the native _curses_ library doesn't work 
well with cscope.

cscope needs to compiling with _ncurses_ library on 
this platform. But there's a bug preventing linking 
with ncurses library:
 
you might configure cscope compiling with ncurses 
library through:
 $ ./configure --with-ncurses

The configure(1) then detectes ncurses library and 
generates Makefiles. But the generated Makefiles are 
hardcoded with:
   -lcurses

--

After correct this problem. cscope(1) works fine.


----------------------------------------------------------------------

>Comment By: Ming Fan (xmfanx)
Date: 2001-08-28 12:34

Message:
Logged In: YES 
user_id=306237

By default, configure(1) trys to build cscope with ncurses 
library. Simply type
 $ ./configure

it will find and verify ncurses library if there's one. 
configure(1) also prints out the version of ncurses 
library. 

It then generate Makefile, config.h, and config.cache. I 
think both config.h and config.cache is OK. The problem is 
that Makefile is generated with one line always hardcoded 
like this:

CURSES_LIBS = -lcurses 

Therefore, cscope will be linked with curses library, 
instead of ncurses library.

Here attached both config.h and config.cache, and Makefile. 
I merge them together into one attachment. Please check.

BTW, I'm using Solaris 8, 01/01 release. Thanks.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 09:15

Message:
Logged In: YES 
user_id=27517

OK, that backtrace essentially proves that the problem is,
indeed, with the curses library you use. I'm not quite sure
I understand how you built your non-ncurses version of the
executable, though. Could you please show the config.h and
config.cache files for that case (mail to me, or Upload into
this bug report form).

----------------------------------------------------------------------

Comment By: Ming Fan (xmfanx)
Date: 2001-08-24 09:37

Message:
Logged In: YES 
user_id=306237

Please check my comments below:

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?

xmfanx> yeah, I'm sure each time I did _make distclean_.

If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

xmfanx> right, but the default build on Solaris yield 
unuseable executable cscope, I'm afraid it's a severe bug. 
As I remember I had the same experience on Solaris (sparc) 
platform. And I have to keep an ancient copy of cscope from 
SUNWspro package.

Anyway: how did you conclude that the curses library was the
root of the original crash?
xmfanx> I assume cscope is stable and has being used alot 
on different platform, my cscope on linux (x86 and PPC) 
works fine, which is built by following the default steps 
(./configure; make; make install). Thus I suspect it's 
library problem on Solaris.

Parsing itself doesn't involve any calls to curses. Only 
the progress bar does --- was that
were your segfault came from?

xmfanx> agreed. So i did something silly. First I tryed to 
use flex instead of default *lex* (make 
distclean; ./configiure --with-flex;
make; make install), then try it on a relatively big 
project (about 4000 source files), failed again.

xmfanx> Then i tried the same to use bison instead of 
default *yacc*, failed again. 

xmfanx> <<<Later I realize cscope 15.3 is actually using 
flex and bison by default. ;) >>>

xmfanx> I thought it might not be a parsing problem. 

xmfanx> Actually during parsing, the curses screen is 
already init'ed, so I tried to use Solaris' native curses 
library instead ncurses, I commented out -DRENAMED_NCURSES. 
At the same time I noticed CURSES_LIBS is defined as -
lcurses though it's conifgured to use ncurses library. It 
failed again.

xmfanx> I fall back to use ncurses library and correct 
CURSES_LIBS to be defined as -lncurses. It works well.

Could you show a backtrace? 
xmfanx> Here you are. 
copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
Core was generated by `cscope'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libcurses.so.1...done.
Loaded symbols for /usr/lib/libcurses.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
#0  0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
#1  0xdfb8723c in w32addch () from /usr/lib/libcurses.so.1
#2  0xdfb7bedf in waddch () from /usr/lib/libcurses.so.1
#3  0x805bf11 in progress (what=0x806e53a "Building symbol 
database", 
    current=80, max=3799) at display.c:561
#4  0x80621d2 in build () at main.c:982
#5  0x8061435 in main (argc=0, argv=0x8047c08) at main.c:563
(gdb) 

--
BTW, I think cscope might have the same problem on all 
Solaris releases. Please check.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:30

Message:
Logged In: YES 
user_id=27517

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?
If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

Anyway: how did you conclude that the curses library was the
root of the original crash? Parsing itself doesn't involve
any calls to curses. Only the progress bar does --- was that
were your segfault came from? Could you show a backtrace?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Bugs item #454741, was opened at 2001-08-23 15:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Category: None
Group: None
Status: Open
Resolution: Postponed
Priority: 5
Submitted By: Ming Fan (xmfanx)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: Segmenation Fault on Solaris X86 (01/01)

Initial Comment:
cscope(v15.3, same as in v15.1) compiled on Solaris 8 
(x86, 01/01 release) and crashed with segmentation 
fault upon parsing source files.

Sounds like the native _curses_ library doesn't work 
well with cscope.

cscope needs to compiling with _ncurses_ library on 
this platform. But there's a bug preventing linking 
with ncurses library:
 
you might configure cscope compiling with ncurses 
library through:
 $ ./configure --with-ncurses

The configure(1) then detectes ncurses library and 
generates Makefiles. But the generated Makefiles are 
hardcoded with:
   -lcurses

--

After correct this problem. cscope(1) works fine.


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-29 05:59

Message:
Logged In: YES 
user_id=27517

OK, I looked at the attached files. The problem seems to be
that configure actually does not manage to find any
installed library -lncurses in any of the places it looks.

Could you please attach config.log, too (from a 'make
distclean ; ./configure --with-ncurses'  run please,
otherwise it'd be mostly empty)? 

So it reverts to looking at -lcurses, but finds out that the
<curses.h> it sees actually belongs to ncurses (it #defined
__NCURSES_H). That's why it's defining -DRENAMED_NCURSES in
$(CURSES_INCLUDEDIR) of the makefile, too.

	./configure --with-ncurses=/where/ever/it/is

may work better, if ncurses is neither in /usr/lib nor
/usr/local/lib.

----------------------------------------------------------------------

Comment By: Ming Fan (xmfanx)
Date: 2001-08-28 12:34

Message:
Logged In: YES 
user_id=306237

By default, configure(1) trys to build cscope with ncurses 
library. Simply type
 $ ./configure

it will find and verify ncurses library if there's one. 
configure(1) also prints out the version of ncurses 
library. 

It then generate Makefile, config.h, and config.cache. I 
think both config.h and config.cache is OK. The problem is 
that Makefile is generated with one line always hardcoded 
like this:

CURSES_LIBS = -lcurses 

Therefore, cscope will be linked with curses library, 
instead of ncurses library.

Here attached both config.h and config.cache, and Makefile. 
I merge them together into one attachment. Please check.

BTW, I'm using Solaris 8, 01/01 release. Thanks.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 09:15

Message:
Logged In: YES 
user_id=27517

OK, that backtrace essentially proves that the problem is,
indeed, with the curses library you use. I'm not quite sure
I understand how you built your non-ncurses version of the
executable, though. Could you please show the config.h and
config.cache files for that case (mail to me, or Upload into
this bug report form).

----------------------------------------------------------------------

Comment By: Ming Fan (xmfanx)
Date: 2001-08-24 09:37

Message:
Logged In: YES 
user_id=306237

Please check my comments below:

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?

xmfanx> yeah, I'm sure each time I did _make distclean_.

If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

xmfanx> right, but the default build on Solaris yield 
unuseable executable cscope, I'm afraid it's a severe bug. 
As I remember I had the same experience on Solaris (sparc) 
platform. And I have to keep an ancient copy of cscope from 
SUNWspro package.

Anyway: how did you conclude that the curses library was the
root of the original crash?
xmfanx> I assume cscope is stable and has being used alot 
on different platform, my cscope on linux (x86 and PPC) 
works fine, which is built by following the default steps 
(./configure; make; make install). Thus I suspect it's 
library problem on Solaris.

Parsing itself doesn't involve any calls to curses. Only 
the progress bar does --- was that
were your segfault came from?

xmfanx> agreed. So i did something silly. First I tryed to 
use flex instead of default *lex* (make 
distclean; ./configiure --with-flex;
make; make install), then try it on a relatively big 
project (about 4000 source files), failed again.

xmfanx> Then i tried the same to use bison instead of 
default *yacc*, failed again. 

xmfanx> <<<Later I realize cscope 15.3 is actually using 
flex and bison by default. ;) >>>

xmfanx> I thought it might not be a parsing problem. 

xmfanx> Actually during parsing, the curses screen is 
already init'ed, so I tried to use Solaris' native curses 
library instead ncurses, I commented out -DRENAMED_NCURSES. 
At the same time I noticed CURSES_LIBS is defined as -
lcurses though it's conifgured to use ncurses library. It 
failed again.

xmfanx> I fall back to use ncurses library and correct 
CURSES_LIBS to be defined as -lncurses. It works well.

Could you show a backtrace? 
xmfanx> Here you are. 
copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public 
License, and you are
welcome to change it and/or distribute copies of it under 
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show 
warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
Core was generated by `cscope'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libcurses.so.1...done.
Loaded symbols for /usr/lib/libcurses.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
#0  0x0 in ?? ()
(gdb) bt
#0  0x0 in ?? ()
#1  0xdfb8723c in w32addch () from /usr/lib/libcurses.so.1
#2  0xdfb7bedf in waddch () from /usr/lib/libcurses.so.1
#3  0x805bf11 in progress (what=0x806e53a "Building symbol 
database", 
    current=80, max=3799) at display.c:561
#4  0x80621d2 in build () at main.c:982
#5  0x8061435 in main (argc=0, argv=0x8047c08) at main.c:563
(gdb) 

--
BTW, I think cscope might have the same problem on all 
Solaris releases. Please check.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:30

Message:
Logged In: YES 
user_id=27517

Did you try configuring from a clean state ('make distclean'
before 'configure') to see if it still read -lcurses?
If all else fails, you can always override the Makefile in
this respect by running

	make CURSES_LIBS=-lncurses

Anyway: how did you conclude that the curses library was the
root of the original crash? Parsing itself doesn't involve
any calls to curses. Only the progress bar does --- was that
were your segfault came from? Could you show a backtrace?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454741&group_id=4664

Bugs item #455948, was opened at 2001-08-27 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455948&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build problem for Cscope in Solaris 5.7

Initial Comment:
Trying to build cscope for solaris 5.7.

Using the instructions given in latest cscope 
INSTALL file.

./configure was successful.
make failed with error as attached in log file.

Please help.

Thanks and regards,
Surajit Dey
sdey@...





----------------------------------------------------------------------

>Comment By: Petr Sorfa (petr)
Date: 2001-08-27 16:43

Message:
Logged In: YES 
user_id=26835

Looks like there is not attachment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455948&group_id=4664

Bugs item #455948, was opened at 2001-08-27 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455948&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build problem for Cscope in Solaris 5.7

Initial Comment:
Trying to build cscope for solaris 5.7.

Using the instructions given in latest cscope 
INSTALL file.

./configure was successful.
make failed with error as attached in log file.

Please help.

Thanks and regards,
Surajit Dey
sdey@...





----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-27 18:48

Message:
Logged In: NO 

coppertone:/home/sdey/cscope>'make'
make  all-recursive
make[1]: Entering directory `/home/sdey/cscope'
Making all in doc
make[2]: Entering directory `/home/sdey/cscope/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/sdey/cscope/doc'
Making all in src
make[2]: Entering directory `/home/sdey/cscope/src'
gcc  -g -O2  -o cscope  scanner.o egrep.o alloc.o 
basename.o command.o compath.o crossref.o dir.o display.o 
edit.o exec.o find.o help.o history.o input.o invlib.o 
logdir.o lookup.o main.o mouse.o mygetenv.o mypopen.o 
vpaccess.o vpfopen.o vpinit.o vpopen.o -lcurses  
Undefined			first referenced
 symbol  			    in file
yywrap                              scanner.o
ld: fatal: Symbol referencing errors. No output written to 
cscope
collect2: ld returned 1 exit status
make[2]: *** [cscope] Error 1
make[2]: Leaving directory `/home/sdey/cscope/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sdey/cscope'
make: *** [all-recursive-am] Error 2


----------------------------------------------------------------------

Comment By: Petr Sorfa (petr)
Date: 2001-08-27 16:43

Message:
Logged In: YES 
user_id=26835

Looks like there is not attachment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455948&group_id=4664

Bugs item #455948, was opened at 2001-08-27 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455948&group_id=4664

Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: Build problem for Cscope in Solaris 5.7

Initial Comment:
Trying to build cscope for solaris 5.7.

Using the instructions given in latest cscope 
INSTALL file.

./configure was successful.
make failed with error as attached in log file.

Please help.

Thanks and regards,
Surajit Dey
sdey@...





----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-28 05:40

Message:
Logged In: YES 
user_id=27517

This is a duplicate of an existing bug report: the problem
is that the flex support library isn't found, but our
'configure' fails to notice that and terminate gracefully.
Note that there is no '-lfl' in the link line of your
transcript --- that's the telltale symptom of this problem. 
To fix this, either:

1) install libfl.a somewhere where the compiler will find it
    (or extend the compiler's library search path
accordingly)
2) Use the latest CVS version of fscanner.l It contains a
change that
    removes the need for yywrap(), and thus for libfl.a,
too.

I'm closing this report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-27 18:48

Message:
Logged In: NO 

coppertone:/home/sdey/cscope>'make'
make  all-recursive
make[1]: Entering directory `/home/sdey/cscope'
Making all in doc
make[2]: Entering directory `/home/sdey/cscope/doc'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/sdey/cscope/doc'
Making all in src
make[2]: Entering directory `/home/sdey/cscope/src'
gcc  -g -O2  -o cscope  scanner.o egrep.o alloc.o 
basename.o command.o compath.o crossref.o dir.o display.o 
edit.o exec.o find.o help.o history.o input.o invlib.o 
logdir.o lookup.o main.o mouse.o mygetenv.o mypopen.o 
vpaccess.o vpfopen.o vpinit.o vpopen.o -lcurses  
Undefined			first referenced
 symbol  			    in file
yywrap                              scanner.o
ld: fatal: Symbol referencing errors. No output written to 
cscope
collect2: ld returned 1 exit status
make[2]: *** [cscope] Error 1
make[2]: Leaving directory `/home/sdey/cscope/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sdey/cscope'
make: *** [all-recursive-am] Error 2


----------------------------------------------------------------------

Comment By: Petr Sorfa (petr)
Date: 2001-08-27 16:43

Message:
Logged In: YES 
user_id=26835

Looks like there is not attachment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455948&group_id=4664

Bugs item #455441, was opened at 2001-08-25 22:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455441&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: c++ style comments handled incorrectly

Initial Comment:
void
Foo_Copy(char *a, // IN
         char *b) // OUT
{
}

Then in cscope enter Foo_Copy in "Find this global
definition":  and it can't.

defining COMMENTS_BY_FLEX to zero in fscanner.l
solves this problem.

----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 03:12

Message:
Logged In: YES 
user_id=27517

That problem is a hard one. Distinguishing function calls
from function declarations, and both from function
definitions, is quite hard enough already. Comments in the
middle of an argument list can make it impossible.

The reason the earlier version worked better is that it's a
two-pass approach: it removes comments, first, and then
looks for syntactical elements. COMMENTS_BY_FLEX does both
in one pass, which causes additional problems.

I'll see what can be done about it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455441&group_id=4664

Bugs item #455441, was opened at 2001-08-25 22:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455441&group_id=4664

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: c++ style comments handled incorrectly

Initial Comment:
void
Foo_Copy(char *a, // IN
         char *b) // OUT
{
}

Then in cscope enter Foo_Copy in "Find this global
definition":  and it can't.

defining COMMENTS_BY_FLEX to zero in fscanner.l
solves this problem.

----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 09:11

Message:
Logged In: YES 
user_id=27517

Fix checked in. CAUTION: I didn't run tests against C++
sources to see if it breaks something elsewhere.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 03:12

Message:
Logged In: YES 
user_id=27517

That problem is a hard one. Distinguishing function calls
from function declarations, and both from function
definitions, is quite hard enough already. Comments in the
middle of an argument list can make it impossible.

The reason the earlier version worked better is that it's a
two-pass approach: it removes comments, first, and then
looks for syntactical elements. COMMENTS_BY_FLEX does both
in one pass, which causes additional problems.

I'll see what can be done about it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=455441&group_id=4664

Bugs item #454678, was opened at 2001-08-23 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: yytext problem on ultra-10 sunos 5.7

Initial Comment:
I installed flex and adjusted my PATH so flex is in it
and lex isn't.
I tried --with-flex option but it didn't help.

Here's some output:
]./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh
-c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... 
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh
-c
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc
-E
checking for flex... (cached) lex
checking for flex... (cached) lex
checking for yywrap in -ll... (cached) yes
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for sys/window.h... (cached) no
checking for sys/termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached)
void
checking for getcwd... (cached) yes
checking for regcmp... (cached) yes
checking for regcomp... (cached) yes
checking for strerror... (cached) yes
checking for vsnprintf... (cached) yes
checking for snprintf... (cached) yes
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
config.h is unchanged
  Sun 560$ kilner@... ~/0/cscope-15.3
]gnumake clean
Making clean in .
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
gnumake[1]: Nothing to be done for `clean-am'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
Making clean in contrib
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/contrib'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/contrib'
Making clean in src
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/src'
test -z "cscope" || rm -f cscope
test -z "scanner.c fscanner.c egrep.c" || rm -f
scanner.c fscanner.c egrep.c
rm -f *.o core *.core
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
Making clean in doc
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
  Sun 561$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "lex" scanner.l lex.yy.c scanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c
scanner.c
In file included from scanner.l:39:
scanner.h:81: conflicting types for `yytext'
scanner.c:623: previous declaration of `yytext'
lex.yy.c: In function `yylex':
lex.yy.c:919: invalid operands to binary -
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: invalid operands to binary -
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: invalid operands to binary -
lex.yy.c:1632: invalid operands to binary -
lex.yy.c: In function `yy_get_next_buffer':
lex.yy.c:1780: invalid operands to binary -
lex.yy.c:1800: invalid operands to binary -
lex.yy.c:1891: `yytext' has an incomplete type
lex.yy.c: In function `yyunput':
lex.yy.c:1995: `yytext' has an incomplete type
lex.yy.c: In function `input':
lex.yy.c:2024: invalid operands to binary -
lex.yy.c: In function `yy_load_buffer_state':
lex.yy.c:2128: `yytext' has an incomplete type
scanner.l: At top level:
scanner.h:81: warning: array `yytext' assumed to have
one element
gnumake[2]: *** [scanner.o] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 562$ kilner@... ~/0/cscope-15.3
]Dooh failed again!


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:23

Message:
Logged In: YES 
user_id=27517

You may have to convince it to really use flex. In order to
do that, it may be necessary to remove that "(cached)"
information produced by earlier "./configure" runs:

	make distclean
	./configure --with-flex

should help.

To see what the problem with the lex-generated scanner.c is,
I may need a copy of it. Esp. the sections close to where
the error messages were reported by the compiler (around
lines 623 and 919 of scanner.c). Either mail them or Upload
them to this bugreport form.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Bugs item #454678, was opened at 2001-08-23 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Hans-Bernhard Broeker (broeker)
Summary: yytext problem on ultra-10 sunos 5.7

Initial Comment:
I installed flex and adjusted my PATH so flex is in it
and lex isn't.
I tried --with-flex option but it didn't help.

Here's some output:
]./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh
-c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... 
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh
-c
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc
-E
checking for flex... (cached) lex
checking for flex... (cached) lex
checking for yywrap in -ll... (cached) yes
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for sys/window.h... (cached) no
checking for sys/termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached)
void
checking for getcwd... (cached) yes
checking for regcmp... (cached) yes
checking for regcomp... (cached) yes
checking for strerror... (cached) yes
checking for vsnprintf... (cached) yes
checking for snprintf... (cached) yes
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
config.h is unchanged
  Sun 560$ kilner@... ~/0/cscope-15.3
]gnumake clean
Making clean in .
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
gnumake[1]: Nothing to be done for `clean-am'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
Making clean in contrib
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/contrib'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/contrib'
Making clean in src
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/src'
test -z "cscope" || rm -f cscope
test -z "scanner.c fscanner.c egrep.c" || rm -f
scanner.c fscanner.c egrep.c
rm -f *.o core *.core
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
Making clean in doc
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
  Sun 561$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "lex" scanner.l lex.yy.c scanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c
scanner.c
In file included from scanner.l:39:
scanner.h:81: conflicting types for `yytext'
scanner.c:623: previous declaration of `yytext'
lex.yy.c: In function `yylex':
lex.yy.c:919: invalid operands to binary -
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: invalid operands to binary -
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: invalid operands to binary -
lex.yy.c:1632: invalid operands to binary -
lex.yy.c: In function `yy_get_next_buffer':
lex.yy.c:1780: invalid operands to binary -
lex.yy.c:1800: invalid operands to binary -
lex.yy.c:1891: `yytext' has an incomplete type
lex.yy.c: In function `yyunput':
lex.yy.c:1995: `yytext' has an incomplete type
lex.yy.c: In function `input':
lex.yy.c:2024: invalid operands to binary -
lex.yy.c: In function `yy_load_buffer_state':
lex.yy.c:2128: `yytext' has an incomplete type
scanner.l: At top level:
scanner.h:81: warning: array `yytext' assumed to have
one element
gnumake[2]: *** [scanner.o] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 562$ kilner@... ~/0/cscope-15.3
]Dooh failed again!


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:23

Message:
Logged In: YES 
user_id=27517

You may have to convince it to really use flex. In order to
do that, it may be necessary to remove that "(cached)"
information produced by earlier "./configure" runs:

	make distclean
	./configure --with-flex

should help.

To see what the problem with the lex-generated scanner.c is,
I may need a copy of it. Esp. the sections close to where
the error messages were reported by the compiler (around
lines 623 and 919 of scanner.c). Either mail them or Upload
them to this bugreport form.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Bugs item #454678, was opened at 2001-08-23 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: yytext problem on ultra-10 sunos 5.7

Initial Comment:
I installed flex and adjusted my PATH so flex is in it
and lex isn't.
I tried --with-flex option but it didn't help.

Here's some output:
]./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh
-c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... 
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh
-c
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc
-E
checking for flex... (cached) lex
checking for flex... (cached) lex
checking for yywrap in -ll... (cached) yes
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for sys/window.h... (cached) no
checking for sys/termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached)
void
checking for getcwd... (cached) yes
checking for regcmp... (cached) yes
checking for regcomp... (cached) yes
checking for strerror... (cached) yes
checking for vsnprintf... (cached) yes
checking for snprintf... (cached) yes
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
config.h is unchanged
  Sun 560$ kilner@... ~/0/cscope-15.3
]gnumake clean
Making clean in .
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
gnumake[1]: Nothing to be done for `clean-am'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
Making clean in contrib
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/contrib'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/contrib'
Making clean in src
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/src'
test -z "cscope" || rm -f cscope
test -z "scanner.c fscanner.c egrep.c" || rm -f
scanner.c fscanner.c egrep.c
rm -f *.o core *.core
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
Making clean in doc
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
  Sun 561$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "lex" scanner.l lex.yy.c scanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c
scanner.c
In file included from scanner.l:39:
scanner.h:81: conflicting types for `yytext'
scanner.c:623: previous declaration of `yytext'
lex.yy.c: In function `yylex':
lex.yy.c:919: invalid operands to binary -
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: invalid operands to binary -
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: invalid operands to binary -
lex.yy.c:1632: invalid operands to binary -
lex.yy.c: In function `yy_get_next_buffer':
lex.yy.c:1780: invalid operands to binary -
lex.yy.c:1800: invalid operands to binary -
lex.yy.c:1891: `yytext' has an incomplete type
lex.yy.c: In function `yyunput':
lex.yy.c:1995: `yytext' has an incomplete type
lex.yy.c: In function `input':
lex.yy.c:2024: invalid operands to binary -
lex.yy.c: In function `yy_load_buffer_state':
lex.yy.c:2128: `yytext' has an incomplete type
scanner.l: At top level:
scanner.h:81: warning: array `yytext' assumed to have
one element
gnumake[2]: *** [scanner.o] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 562$ kilner@... ~/0/cscope-15.3
]Dooh failed again!


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-24 09:39

Message:
Logged In: NO 

Ok if I log in with my password do I get to upload files..
Lets see!

I'm trying to upload a tar'd version of what I compiled for
cscope and
flex along with captued text showing commands I entered and
a few
other things.

I made a quick attempt at editing  configure  to make it
chose flex nomatter what but it didn't work. I did try the
--with-flex option before
and it didn't help.

In the tar'd up cscope is a file
A_COMPILE_ATTEMPT_WITH_OUTPUT.T

The current executable of cscope started getting segfaults
which is why
I wanted to have the source so I could compile it with debug
options and
use gdb if the problem didn't go away. I ended up just
filtering my file
list that it scans and that fixed it.

I use cscope with a big forth code source tree (openboot) so
I need to give it the list of files and then scan for just
text and that works great! for finding stuff.

Thanks
-Fred

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:23

Message:
Logged In: YES 
user_id=27517

You may have to convince it to really use flex. In order to
do that, it may be necessary to remove that "(cached)"
information produced by earlier "./configure" runs:

	make distclean
	./configure --with-flex

should help.

To see what the problem with the lex-generated scanner.c is,
I may need a copy of it. Esp. the sections close to where
the error messages were reported by the compiler (around
lines 623 and 919 of scanner.c). Either mail them or Upload
them to this bugreport form.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Bugs item #454678, was opened at 2001-08-23 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: yytext problem on ultra-10 sunos 5.7

Initial Comment:
I installed flex and adjusted my PATH so flex is in it
and lex isn't.
I tried --with-flex option but it didn't help.

Here's some output:
]./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh
-c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... 
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh
-c
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc
-E
checking for flex... (cached) lex
checking for flex... (cached) lex
checking for yywrap in -ll... (cached) yes
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for sys/window.h... (cached) no
checking for sys/termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached)
void
checking for getcwd... (cached) yes
checking for regcmp... (cached) yes
checking for regcomp... (cached) yes
checking for strerror... (cached) yes
checking for vsnprintf... (cached) yes
checking for snprintf... (cached) yes
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
config.h is unchanged
  Sun 560$ kilner@... ~/0/cscope-15.3
]gnumake clean
Making clean in .
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
gnumake[1]: Nothing to be done for `clean-am'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
Making clean in contrib
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/contrib'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/contrib'
Making clean in src
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/src'
test -z "cscope" || rm -f cscope
test -z "scanner.c fscanner.c egrep.c" || rm -f
scanner.c fscanner.c egrep.c
rm -f *.o core *.core
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
Making clean in doc
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
  Sun 561$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "lex" scanner.l lex.yy.c scanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c
scanner.c
In file included from scanner.l:39:
scanner.h:81: conflicting types for `yytext'
scanner.c:623: previous declaration of `yytext'
lex.yy.c: In function `yylex':
lex.yy.c:919: invalid operands to binary -
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: invalid operands to binary -
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: invalid operands to binary -
lex.yy.c:1632: invalid operands to binary -
lex.yy.c: In function `yy_get_next_buffer':
lex.yy.c:1780: invalid operands to binary -
lex.yy.c:1800: invalid operands to binary -
lex.yy.c:1891: `yytext' has an incomplete type
lex.yy.c: In function `yyunput':
lex.yy.c:1995: `yytext' has an incomplete type
lex.yy.c: In function `input':
lex.yy.c:2024: invalid operands to binary -
lex.yy.c: In function `yy_load_buffer_state':
lex.yy.c:2128: `yytext' has an incomplete type
scanner.l: At top level:
scanner.h:81: warning: array `yytext' assumed to have
one element
gnumake[2]: *** [scanner.o] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 562$ kilner@... ~/0/cscope-15.3
]Dooh failed again!


----------------------------------------------------------------------

Comment By: Fred W Kilner Genius (stupidfred)
Date: 2001-08-24 10:11

Message:
Logged In: YES 
user_id=306965

How do I upload files? I don't see a spot to do that.

I went to the ftp.sorceforge.net but didn't see an upload
directory.

Hmmm. I could try putting file on my ucsc webpage if you
don't have an
upload spot.

-Fred


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-24 09:39

Message:
Logged In: NO 

Ok if I log in with my password do I get to upload files..
Lets see!

I'm trying to upload a tar'd version of what I compiled for
cscope and
flex along with captued text showing commands I entered and
a few
other things.

I made a quick attempt at editing  configure  to make it
chose flex nomatter what but it didn't work. I did try the
--with-flex option before
and it didn't help.

In the tar'd up cscope is a file
A_COMPILE_ATTEMPT_WITH_OUTPUT.T

The current executable of cscope started getting segfaults
which is why
I wanted to have the source so I could compile it with debug
options and
use gdb if the problem didn't go away. I ended up just
filtering my file
list that it scans and that fixed it.

I use cscope with a big forth code source tree (openboot) so
I need to give it the list of files and then scan for just
text and that works great! for finding stuff.

Thanks
-Fred

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:23

Message:
Logged In: YES 
user_id=27517

You may have to convince it to really use flex. In order to
do that, it may be necessary to remove that "(cached)"
information produced by earlier "./configure" runs:

	make distclean
	./configure --with-flex

should help.

To see what the problem with the lex-generated scanner.c is,
I may need a copy of it. Esp. the sections close to where
the error messages were reported by the compiler (around
lines 623 and 919 of scanner.c). Either mail them or Upload
them to this bugreport form.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Bugs item #454678, was opened at 2001-08-23 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: yytext problem on ultra-10 sunos 5.7

Initial Comment:
I installed flex and adjusted my PATH so flex is in it
and lex isn't.
I tried --with-flex option but it didn't help.

Here's some output:
]./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh
-c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... 
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh
-c
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc
-E
checking for flex... (cached) lex
checking for flex... (cached) lex
checking for yywrap in -ll... (cached) yes
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for sys/window.h... (cached) no
checking for sys/termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached)
void
checking for getcwd... (cached) yes
checking for regcmp... (cached) yes
checking for regcomp... (cached) yes
checking for strerror... (cached) yes
checking for vsnprintf... (cached) yes
checking for snprintf... (cached) yes
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
config.h is unchanged
  Sun 560$ kilner@... ~/0/cscope-15.3
]gnumake clean
Making clean in .
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
gnumake[1]: Nothing to be done for `clean-am'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
Making clean in contrib
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/contrib'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/contrib'
Making clean in src
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/src'
test -z "cscope" || rm -f cscope
test -z "scanner.c fscanner.c egrep.c" || rm -f
scanner.c fscanner.c egrep.c
rm -f *.o core *.core
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
Making clean in doc
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
  Sun 561$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "lex" scanner.l lex.yy.c scanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c
scanner.c
In file included from scanner.l:39:
scanner.h:81: conflicting types for `yytext'
scanner.c:623: previous declaration of `yytext'
lex.yy.c: In function `yylex':
lex.yy.c:919: invalid operands to binary -
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: invalid operands to binary -
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: invalid operands to binary -
lex.yy.c:1632: invalid operands to binary -
lex.yy.c: In function `yy_get_next_buffer':
lex.yy.c:1780: invalid operands to binary -
lex.yy.c:1800: invalid operands to binary -
lex.yy.c:1891: `yytext' has an incomplete type
lex.yy.c: In function `yyunput':
lex.yy.c:1995: `yytext' has an incomplete type
lex.yy.c: In function `input':
lex.yy.c:2024: invalid operands to binary -
lex.yy.c: In function `yy_load_buffer_state':
lex.yy.c:2128: `yytext' has an incomplete type
scanner.l: At top level:
scanner.h:81: warning: array `yytext' assumed to have
one element
gnumake[2]: *** [scanner.o] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 562$ kilner@... ~/0/cscope-15.3
]Dooh failed again!


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-24 15:58

Message:
Logged In: NO 

I did make dist-clean and then did configure with
--with-flex
Now the problem is during linking:
Undefined                       first referenced
 symbol                             in file
yywrap                              fscanner.o
ld: fatal: Symbol referencing errors. No output written to

Below is the configure, and compile output followed by the
beginning of fscanner.c There was no scanner.c generated
-Fred


]./configure --with-flex
creating cache ./config.cache
checking for a BSD compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... flex
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh -c
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for flex... flex
checking for flex... (cached) flex
checking for yywrap in -lfl... no
checking lex output file root... lex.yy
checking whether yytext is a pointer... no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for ANSI C header files... yes
checking for fcntl.h... yes
checking for sys/window.h... no
checking for sys/termios.h... yes
checking for unistd.h... yes
checking for working const... yes
checking for mode_t... yes
checking for pid_t... yes
checking for size_t... yes
checking return type of signal handlers... void
checking for getcwd... yes
checking for regcmp... yes
checking for regcomp... yes
checking for strerror... yes
checking for vsnprintf... yes
checking for snprintf... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
  Sun 572$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory `/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "flex" fscanner.l lex.yy.c fscanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c fscanner.c
yacc   egrep.y && mv y.tab.c egrep.c

conflicts: 2 shift/reduce
if test -f y.tab.h; then \
if cmp -s y.tab.h egrep.h; then rm -f y.tab.h; else mv
y.tab.h egrep.h; fi; \
else :; fi
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c egrep.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c alloc.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c basename.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c command.c
In file included from /usr/include/ncurses.h:23,
                 from command.c:41:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c compath.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c crossref.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c dir.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c display.c
In file included from /usr/include/ncurses.h:23,
                 from display.c:45:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c edit.c
In file included from /usr/include/ncurses.h:23,
                 from edit.c:40:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c exec.c
In file included from /usr/include/ncurses.h:23,
                 from exec.c:47:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c find.c
In file included from /usr/include/ncurses.h:23,
                 from find.c:41:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c help.c
In file included from /usr/include/ncurses.h:23,
                 from help.c:41:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c history.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c input.c
In file included from /usr/include/ncurses.h:23,
                 from input.c:40:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c invlib.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c logdir.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c lookup.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c main.c
In file included from /usr/include/ncurses.h:23,
                 from main.c:45:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c mouse.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c mygetenv.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c mypopen.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpaccess.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpfopen.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpinit.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpopen.c
gcc  -g -O2  -o cscope  fscanner.o egrep.o alloc.o
basename.o command.o compath.o crossref.o dir.o display.o
edit.o exec.o find.o help.o history.o input.o invlib.o
logdir.o lookup.o main.o mouse.o mygetenv.o mypopen.o
vpaccess.o vpfopen.o vpinit.o vpopen.o -lncurses  
Undefined                       first referenced
 symbol                             in file
yywrap                              fscanner.o
ld: fatal: Symbol referencing errors. No output written to
cscope
collect2: ld returned 1 exit status
gnumake[2]: *** [cscope] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory `/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 573$ kilner@... ~/0/cscope-15.3
]



/* A lexical scanner generated by flex */

/* Scanner skeleton version:
 * $Header: /home/daffy/u0/vern/flex/RCS/flex.skl,v 2.91
96/09/10 16:58:48 vern Exp $
 */

#define FLEX_SCANNER
#define YY_FLEX_MAJOR_VERSION 2
#define YY_FLEX_MINOR_VERSION 5

#include <stdio.h>


/* cfront 1.2 defines "c_plusplus" instead of "__cplusplus"
*/
#ifdef c_plusplus
#ifndef __cplusplus
#define __cplusplus
#endif
#endif


#ifdef __cplusplus

#include <stdlib.h>
#include <unistd.h>

/* Use prototypes in function declarations. */
#define YY_USE_PROTOS

/* The "const" storage-class-modifier is valid. */
#define YY_USE_CONST

#else   /* ! __cplusplus */

#if __STDC__

#define YY_USE_PROTOS
#define YY_USE_CONST

#endif  /* __STDC__ */
#endif  /* ! __cplusplus */

#ifdef __TURBOC__
 #pragma warn -rch
 #pragma warn -use
#include <io.h>
#include <stdlib.h>
#define YY_USE_CONST
#define YY_USE_PROTOS
#endif

#ifdef YY_USE_CONST
#define yyconst const
#else
#define yyconst
#endif


#ifdef YY_USE_PROTOS
#define YY_PROTO(proto) proto
#else
#define YY_PROTO(proto) ()
#endif

/* Returned upon end-of-file. */
#define YY_NULL 0

/* Promotes a possibly negative, possibly signed char to an
unsigned
 * integer for use as an array index.  If the signed char is
negative,
 * we want to instead treat it as an 8-bit unsigned char,
hence the
 * double cast.
 */
#define YY_SC_TO_UI(c) ((unsigned int) (unsigned char) c)

/* Enter a start condition.  This macro really ought to take
a parameter,
 * but we do it the disgusting crufty way forced on us by
the ()-less
 * definition of BEGIN.
 */
#define BEGIN yy_start = 1 + 2 *

/* Translate the current start state into a value that can
be later handed
 * to BEGIN to return to the state.  The YYSTATE alias is
for lex
 * compatibility.
 */
#define YY_START ((yy_start - 1) / 2)
#define YYSTATE YY_START

/* Action number for EOF rule of a given start state. */
#define YY_STATE_EOF(state) (YY_END_OF_BUFFER + state + 1)

/* Special action meaning "start processing a new file". */
#define YY_NEW_FILE yyrestart( yyin )

#define YY_END_OF_BUFFER_CHAR 0

/* Size of default input buffer. */
#define YY_BUF_SIZE 16384

typedef struct yy_buffer_state *YY_BUFFER_STATE;

extern int yyleng;
extern FILE *yyin, *yyout;

#define EOB_ACT_CONTINUE_SCAN 0
#define EOB_ACT_END_OF_FILE 1
#define EOB_ACT_LAST_MATCH 2

/* The funky do-while in the following #define is used to
turn the definition
 * int a single C statement (which needs a semi-colon
terminator).  This
 * avoids problems with code like:
 *
 *      if ( condition_holds )
 *              yyless( 5 );
 *      else
 *              do_something_else();
 *
 * Prior to using the do-while the compiler would get upset
at the
 * "else" because it interpreted the "if" statement as being
all
 * done when it reached the ';' after the yyless() call.
 */

/* Return all but the first 'n' matched characters back to
the input stream. */

#define yyless(n) \
        do \
                { \
                /* Undo effects of setting up yytext. */ \
                *yy_cp = yy_hold_char; \
                YY_RESTORE_YY_MORE_OFFSET \
                yy_c_buf_p = yy_cp = yy_bp + n -
YY_MORE_ADJ; \
                YY_DO_BEFORE_ACTION; /* set up yytext again
*/ \
                } \
        while ( 0 )

#define unput(c) yyunput( c, yytext_ptr )

/* The following is because we cannot portably get our hands
on size_t
 * (without autoconf's help, which isn't available because
we want
 * flex-generated scanners to compile on their own).
 */
typedef unsigned int yy_size_t;


struct yy_buffer_state
        {
        FILE *yy_input_file;

        char *yy_ch_buf;                /* input buffer */
        char *yy_buf_pos;               /* current position
in input buffer */

        /* Size of input buffer in bytes, not including room
for EOB
         * characters.
         */
        yy_size_t yy_buf_size;

        /* Number of characters read into yy_ch_buf, not
including EOB
         * characters.
         */
        int yy_n_chars;

        /* Whether we "own" the buffer - i.e., we know we
created it,
         * and can realloc() it to grow it, and should
free() it to
         * delete it.
         */
        int yy_is_our_buffer;

        /* Whether this is an "interactive" input source; if
so, and
         * if we're using stdio for input, then we want to
use getc()
         * instead of fread(), to make sure we stop fetching
input after
         * each newline.
         */
        int yy_is_interactive;

        /* Whether we're considered to be at the beginning
of a line.
         * If so, '^' rules will be active on the next
match, otherwise
         * not.
         */
        int yy_at_bol;

        /* Whether to try to fill the input buffer when we
reach the
         * end of it.
         */
        int yy_fill_buffer;

        int yy_buffer_status;
#define YY_BUFFER_NEW 0
#define YY_BUFFER_NORMAL 1
        /* When an EOF's been seen but there's still some
text to process
         * then we mark the buffer as YY_EOF_PENDING, to
indicate that we
         * shouldn't try reading from the input source any
more.  We might
         * still have a bunch of tokens to match, though,
because of
         * possible backing-up.
         *
         * When we actually see the EOF, we change the
status to "new"
         * (via yyrestart()), so that the user can continue
scanning by
         * just pointing yyin at a new input file.
         */
#define YY_BUFFER_EOF_PENDING 2
        };

static YY_BUFFER_STATE yy_current_buffer = 0;

/* We provide macros for accessing buffer states in case in
the
 * future we want to put the buffer states in a more general
 * "scanner state".
 */
#define YY_CURRENT_BUFFER yy_current_buffer


/* yy_hold_char holds the character lost when yytext is
formed. */
static char yy_hold_char;

static int yy_n_chars;          /* number of characters read
into yy_ch_buf */


int yyleng;

/* Points to current character in buffer. */
static char *yy_c_buf_p = (char *) 0;
static int yy_init = 1;         /* whether we need to
initialize */
static int yy_start = 0;        /* start state number */

/* Flag which is used to allow yywrap()'s to do buffer
switches
 * instead of setting up a fresh yyin.  A bit of a hack ...
 */
static int yy_did_buffer_switch_on_eof;

void yyrestart YY_PROTO(( FILE *input_file ));

void yy_switch_to_buffer YY_PROTO(( YY_BUFFER_STATE
new_buffer ));
void yy_load_buffer_state YY_PROTO(( void ));
YY_BUFFER_STATE yy_create_buffer YY_PROTO(( FILE *file, int
size ));
void yy_delete_buffer YY_PROTO(( YY_BUFFER_STATE b ));
void yy_init_buffer YY_PROTO(( YY_BUFFER_STATE b, FILE *file
));
void yy_flush_buffer YY_PROTO(( YY_BUFFER_STATE b ));
#define YY_FLUSH_BUFFER yy_flush_buffer( yy_current_buffer )

YY_BUFFER_STATE yy_scan_buffer YY_PROTO(( char *base,
yy_size_t size ));
YY_BUFFER_STATE yy_scan_string YY_PROTO(( yyconst char
*yy_str ));
YY_BUFFER_STATE yy_scan_bytes YY_PROTO(( yyconst char
*bytes, int len ));

static void *yy_flex_alloc YY_PROTO(( yy_size_t ));
static void *yy_flex_realloc YY_PROTO(( void *, yy_size_t
));
static void yy_flex_free YY_PROTO(( void * ));

#define yy_new_buffer yy_create_buffer

#define yy_set_interactive(is_interactive) \
        { \
        if ( ! yy_current_buffer ) \
                yy_current_buffer = yy_create_buffer( yyin,
YY_BUF_SIZE ); \
        yy_current_buffer->yy_is_interactive =
is_interactive; \
        }

#define yy_set_bol(at_bol) \
        { \
        if ( ! yy_current_buffer ) \
                yy_current_buffer = yy_create_buffer( yyin,
YY_BUF_SIZE ); \
        yy_current_buffer->yy_at_bol = at_bol; \
        }

#define YY_AT_BOL() (yy_current_buffer->yy_at_bol)

typedef unsigned char YY_CHAR;
FILE *yyin = (FILE *) 0, *yyout = (FILE *) 0;
typedef int yy_state_type;
extern char *yytext;
#define yytext_ptr yytext

static yy_state_type yy_get_previous_state YY_PROTO(( void
));
static yy_state_type yy_try_NUL_trans YY_PROTO((
yy_state_type current_state ));
static int yy_get_next_buffer YY_PROTO(( void ));
static void yy_fatal_error YY_PROTO(( yyconst char msg[] ));

/* Done after the current pattern has been matched and
before the
 * corresponding action - sets up yytext.
 */
#define YY_DO_BEFORE_ACTION \
        yytext_ptr = yy_bp; \
        yyleng = (int) (yy_cp - yy_bp); \
        yy_hold_char = *yy_cp; \
        *yy_cp = '\0'; \
        yy_c_buf_p = yy_cp;

#define YY_NUM_RULES 64
#define YY_END_OF_BUFFER 65
static yyconst short int yy_accept[596] =
    {   0,
        0,    0,    0,    0,    0,    0,    0,    0,   
0,    0,
       32,   32,    0,    0,    0,    0,   55,   55,   65,  
63,
       63,   43,   46,    7,   35,   63,   44,   21,   22,  
25,
       63,   63,   61,   24,   26,   23,   40,   63,   41,  
35,
       35,   35,   35,   35,    6,   20,   52,   52,   63,  
35,
       35,    8,    8,    8,    8,    8,   64,   12,   39,  
39,
       39,   37,   39,   33,   32,   33,   31,   50,   48,  
47,
       50,   45,   55,   57,   56,   53,    7,   35,   
1,    2,
       61,   54,   60,   61,   42,   35,   35,   35,   35,  
35,
       52,   52,    3,   35,   35,    9,    9,    9,   
9,    9,

        9,   12,    0,    0,    0,    0,   38,   37,    0,  
37,
       37,   37,    0,    0,    0,   32,   32,    0,  
31,    0,
       49,   51,   55,   57,   56,   58,   56,   59,   53,  
60,
       60,   35,   35,    0,   34,    0,   35,   35,   52,  
35,
       35,    9,    9,    9,    9,   15,    9,    9,   
9,    0,
        0,    0,   38,   37,   37,    0,   36,    0,   
0,    0,
        0,   32,   32,    0,   30,    0,    0,   35,  
29,    0,
       35,   35,   35,   35,    9,    9,    9,    9,   
9,    9,
        9,    0,    0,    0,    0,    0,    0,    0,   
0,    0,
        0,    0,   35,    0,    0,   35,   35,   35,    9,  
17,

       16,    9,    9,    9,    9,   11,    0,    0,   
0,    0,



----------------------------------------------------------------------

Comment By: Fred W Kilner Genius (stupidfred)
Date: 2001-08-24 10:11

Message:
Logged In: YES 
user_id=306965

How do I upload files? I don't see a spot to do that.

I went to the ftp.sorceforge.net but didn't see an upload
directory.

Hmmm. I could try putting file on my ucsc webpage if you
don't have an
upload spot.

-Fred


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-24 09:39

Message:
Logged In: NO 

Ok if I log in with my password do I get to upload files..
Lets see!

I'm trying to upload a tar'd version of what I compiled for
cscope and
flex along with captued text showing commands I entered and
a few
other things.

I made a quick attempt at editing  configure  to make it
chose flex nomatter what but it didn't work. I did try the
--with-flex option before
and it didn't help.

In the tar'd up cscope is a file
A_COMPILE_ATTEMPT_WITH_OUTPUT.T

The current executable of cscope started getting segfaults
which is why
I wanted to have the source so I could compile it with debug
options and
use gdb if the problem didn't go away. I ended up just
filtering my file
list that it scans and that fixed it.

I use cscope with a big forth code source tree (openboot) so
I need to give it the list of files and then scan for just
text and that works great! for finding stuff.

Thanks
-Fred

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:23

Message:
Logged In: YES 
user_id=27517

You may have to convince it to really use flex. In order to
do that, it may be necessary to remove that "(cached)"
information produced by earlier "./configure" runs:

	make distclean
	./configure --with-flex

should help.

To see what the problem with the lex-generated scanner.c is,
I may need a copy of it. Esp. the sections close to where
the error messages were reported by the compiler (around
lines 623 and 919 of scanner.c). Either mail them or Upload
them to this bugreport form.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Bugs item #454678, was opened at 2001-08-23 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: yytext problem on ultra-10 sunos 5.7

Initial Comment:
I installed flex and adjusted my PATH so flex is in it
and lex isn't.
I tried --with-flex option but it didn't help.

Here's some output:
]./configure
loading cache ./config.cache
checking for a BSD compatible install... ./install-sh
-c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... 
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh
-c
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc
-E
checking for flex... (cached) lex
checking for flex... (cached) lex
checking for yywrap in -ll... (cached) yes
checking lex output file root... (cached) lex.yy
checking whether yytext is a pointer... (cached) no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... (cached) yes
checking for opendir in -ldir... (cached) no
checking for ANSI C header files... (cached) yes
checking for fcntl.h... (cached) yes
checking for sys/window.h... (cached) no
checking for sys/termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for working const... (cached) yes
checking for mode_t... (cached) yes
checking for pid_t... (cached) yes
checking for size_t... (cached) yes
checking return type of signal handlers... (cached)
void
checking for getcwd... (cached) yes
checking for regcmp... (cached) yes
checking for regcomp... (cached) yes
checking for strerror... (cached) yes
checking for vsnprintf... (cached) yes
checking for snprintf... (cached) yes
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
config.h is unchanged
  Sun 560$ kilner@... ~/0/cscope-15.3
]gnumake clean
Making clean in .
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
gnumake[1]: Nothing to be done for `clean-am'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
Making clean in contrib
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/contrib'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/contrib'
Making clean in src
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/src'
test -z "cscope" || rm -f cscope
test -z "scanner.c fscanner.c egrep.c" || rm -f
scanner.c fscanner.c egrep.c
rm -f *.o core *.core
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
Making clean in doc
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[1]: Nothing to be done for `clean'.
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
  Sun 561$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory
`/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "lex" scanner.l lex.yy.c scanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c
scanner.c
In file included from scanner.l:39:
scanner.h:81: conflicting types for `yytext'
scanner.c:623: previous declaration of `yytext'
lex.yy.c: In function `yylex':
lex.yy.c:919: invalid operands to binary -
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: `yytext' has an incomplete type
lex.yy.c:994: invalid operands to binary -
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: `yytext' has an incomplete type
scanner.l:515: invalid operands to binary -
lex.yy.c:1632: invalid operands to binary -
lex.yy.c: In function `yy_get_next_buffer':
lex.yy.c:1780: invalid operands to binary -
lex.yy.c:1800: invalid operands to binary -
lex.yy.c:1891: `yytext' has an incomplete type
lex.yy.c: In function `yyunput':
lex.yy.c:1995: `yytext' has an incomplete type
lex.yy.c: In function `input':
lex.yy.c:2024: invalid operands to binary -
lex.yy.c: In function `yy_load_buffer_state':
lex.yy.c:2128: `yytext' has an incomplete type
scanner.l: At top level:
scanner.h:81: warning: array `yytext' assumed to have
one element
gnumake[2]: *** [scanner.o] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory
`/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 562$ kilner@... ~/0/cscope-15.3
]Dooh failed again!


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-27 03:04

Message:
Logged In: YES 
user_id=27517

The remaining problem is partly in your flex installation.
Note this configure output line:

	checking for yywrap in -lfl... no

This means that configure failed to find your 'libfl'. It
should probably stop immediately at that point and refuse to
cooperate until that is fixed, but unfortunately it doesn't,
at the moment.

The latest CVS version of cscope contains a change that
removes the need for yywrap() altogether, and thus the need
for libfl (fscanner.l as of version 1.6).

As to your previous question about uploading: there's a HTML
form for that at the bottom of the bugreport page at SF.
Note the "Check to Upload & Attach" box and the filename
entry field (with the "Browse" button next to it).

And you should re-check your GCC and Sun SDK installations:
those redefinition warnings among two system-supplied
headerfiles shouldn't happen.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-24 15:58

Message:
Logged In: NO 

I did make dist-clean and then did configure with
--with-flex
Now the problem is during linking:
Undefined                       first referenced
 symbol                             in file
yywrap                              fscanner.o
ld: fatal: Symbol referencing errors. No output written to

Below is the configure, and compile output followed by the
beginning of fscanner.c There was no scanner.c generated
-Fred


]./configure --with-flex
creating cache ./config.cache
checking for a BSD compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking host system type... sparc-sun-solaris2.7
checking user specification of lexer... flex
checking user specification of yacc... 
checking for a BSD compatible install... ./install-sh -c
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a
cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for flex... flex
checking for flex... (cached) flex
checking for yywrap in -lfl... no
checking lex output file root... lex.yy
checking whether yytext is a pointer... no
checking for bison... no
checking for byacc... no
checking location of ncurses.h file
Found ncurses on /usr/include/ncurses.h
checking for ncurses version... VERSION:NCURSES_VERSION
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for ANSI C header files... yes
checking for fcntl.h... yes
checking for sys/window.h... no
checking for sys/termios.h... yes
checking for unistd.h... yes
checking for working const... yes
checking for mode_t... yes
checking for pid_t... yes
checking for size_t... yes
checking return type of signal handlers... void
checking for getcwd... yes
checking for regcmp... yes
checking for regcomp... yes
checking for strerror... yes
checking for vsnprintf... yes
checking for snprintf... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating doc/Makefile
creating src/Makefile
creating contrib/Makefile
creating config.h
  Sun 572$ kilner@... ~/0/cscope-15.3
]gnumake
gnumake  all-recursive
gnumake[1]: Entering directory `/home/kilner/0/cscope-15.3'
Making all in doc
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/doc'
gnumake[2]: Nothing to be done for `all'.
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/doc'
Making all in src
gnumake[2]: Entering directory
`/home/kilner/0/cscope-15.3/src'
/bin/sh ./ylwrap "flex" fscanner.l lex.yy.c fscanner.c --  
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c fscanner.c
yacc   egrep.y && mv y.tab.c egrep.c

conflicts: 2 shift/reduce
if test -f y.tab.h; then \
if cmp -s y.tab.h egrep.h; then rm -f y.tab.h; else mv
y.tab.h egrep.h; fi; \
else :; fi
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c egrep.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c alloc.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c basename.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c command.c
In file included from /usr/include/ncurses.h:23,
                 from command.c:41:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c compath.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c crossref.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c dir.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c display.c
In file included from /usr/include/ncurses.h:23,
                 from display.c:45:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c edit.c
In file included from /usr/include/ncurses.h:23,
                 from edit.c:40:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c exec.c
In file included from /usr/include/ncurses.h:23,
                 from exec.c:47:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c find.c
In file included from /usr/include/ncurses.h:23,
                 from find.c:41:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c help.c
In file included from /usr/include/ncurses.h:23,
                 from help.c:41:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c history.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c input.c
In file included from /usr/include/ncurses.h:23,
                 from input.c:40:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c invlib.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c logdir.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c lookup.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c main.c
In file included from /usr/include/ncurses.h:23,
                 from main.c:45:
/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of
the previous definition
/usr/include/widec.h:43: warning: `putwc' redefined
/usr/include/wchar.h:329: warning: this is the location of
the previous definition
/usr/include/widec.h:44: warning: `getwchar' redefined
/usr/include/wchar.h:327: warning: this is the location of
the previous definition
/usr/include/widec.h:45: warning: `putwchar' redefined
/usr/include/wchar.h:330: warning: this is the location of
the previous definition
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c mouse.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c mygetenv.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c mypopen.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpaccess.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpfopen.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpinit.c
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c vpopen.c
gcc  -g -O2  -o cscope  fscanner.o egrep.o alloc.o
basename.o command.o compath.o crossref.o dir.o display.o
edit.o exec.o find.o help.o history.o input.o invlib.o
logdir.o lookup.o main.o mouse.o mygetenv.o mypopen.o
vpaccess.o vpfopen.o vpinit.o vpopen.o -lncurses  
Undefined                       first referenced
 symbol                             in file
yywrap                              fscanner.o
ld: fatal: Symbol referencing errors. No output written to
cscope
collect2: ld returned 1 exit status
gnumake[2]: *** [cscope] Error 1
gnumake[2]: Leaving directory
`/home/kilner/0/cscope-15.3/src'
gnumake[1]: *** [all-recursive] Error 1
gnumake[1]: Leaving directory `/home/kilner/0/cscope-15.3'
gnumake: *** [all-recursive-am] Error 2
  Sun 573$ kilner@... ~/0/cscope-15.3
]



/* A lexical scanner generated by flex */

/* Scanner skeleton version:
 * $Header: /home/daffy/u0/vern/flex/RCS/flex.skl,v 2.91
96/09/10 16:58:48 vern Exp $
 */

#define FLEX_SCANNER
#define YY_FLEX_MAJOR_VERSION 2
#define YY_FLEX_MINOR_VERSION 5

#include <stdio.h>


/* cfront 1.2 defines "c_plusplus" instead of "__cplusplus"
*/
#ifdef c_plusplus
#ifndef __cplusplus
#define __cplusplus
#endif
#endif


#ifdef __cplusplus

#include <stdlib.h>
#include <unistd.h>

/* Use prototypes in function declarations. */
#define YY_USE_PROTOS

/* The "const" storage-class-modifier is valid. */
#define YY_USE_CONST

#else   /* ! __cplusplus */

#if __STDC__

#define YY_USE_PROTOS
#define YY_USE_CONST

#endif  /* __STDC__ */
#endif  /* ! __cplusplus */

#ifdef __TURBOC__
 #pragma warn -rch
 #pragma warn -use
#include <io.h>
#include <stdlib.h>
#define YY_USE_CONST
#define YY_USE_PROTOS
#endif

#ifdef YY_USE_CONST
#define yyconst const
#else
#define yyconst
#endif


#ifdef YY_USE_PROTOS
#define YY_PROTO(proto) proto
#else
#define YY_PROTO(proto) ()
#endif

/* Returned upon end-of-file. */
#define YY_NULL 0

/* Promotes a possibly negative, possibly signed char to an
unsigned
 * integer for use as an array index.  If the signed char is
negative,
 * we want to instead treat it as an 8-bit unsigned char,
hence the
 * double cast.
 */
#define YY_SC_TO_UI(c) ((unsigned int) (unsigned char) c)

/* Enter a start condition.  This macro really ought to take
a parameter,
 * but we do it the disgusting crufty way forced on us by
the ()-less
 * definition of BEGIN.
 */
#define BEGIN yy_start = 1 + 2 *

/* Translate the current start state into a value that can
be later handed
 * to BEGIN to return to the state.  The YYSTATE alias is
for lex
 * compatibility.
 */
#define YY_START ((yy_start - 1) / 2)
#define YYSTATE YY_START

/* Action number for EOF rule of a given start state. */
#define YY_STATE_EOF(state) (YY_END_OF_BUFFER + state + 1)

/* Special action meaning "start processing a new file". */
#define YY_NEW_FILE yyrestart( yyin )

#define YY_END_OF_BUFFER_CHAR 0

/* Size of default input buffer. */
#define YY_BUF_SIZE 16384

typedef struct yy_buffer_state *YY_BUFFER_STATE;

extern int yyleng;
extern FILE *yyin, *yyout;

#define EOB_ACT_CONTINUE_SCAN 0
#define EOB_ACT_END_OF_FILE 1
#define EOB_ACT_LAST_MATCH 2

/* The funky do-while in the following #define is used to
turn the definition
 * int a single C statement (which needs a semi-colon
terminator).  This
 * avoids problems with code like:
 *
 *      if ( condition_holds )
 *              yyless( 5 );
 *      else
 *              do_something_else();
 *
 * Prior to using the do-while the compiler would get upset
at the
 * "else" because it interpreted the "if" statement as being
all
 * done when it reached the ';' after the yyless() call.
 */

/* Return all but the first 'n' matched characters back to
the input stream. */

#define yyless(n) \
        do \
                { \
                /* Undo effects of setting up yytext. */ \
                *yy_cp = yy_hold_char; \
                YY_RESTORE_YY_MORE_OFFSET \
                yy_c_buf_p = yy_cp = yy_bp + n -
YY_MORE_ADJ; \
                YY_DO_BEFORE_ACTION; /* set up yytext again
*/ \
                } \
        while ( 0 )

#define unput(c) yyunput( c, yytext_ptr )

/* The following is because we cannot portably get our hands
on size_t
 * (without autoconf's help, which isn't available because
we want
 * flex-generated scanners to compile on their own).
 */
typedef unsigned int yy_size_t;


struct yy_buffer_state
        {
        FILE *yy_input_file;

        char *yy_ch_buf;                /* input buffer */
        char *yy_buf_pos;               /* current position
in input buffer */

        /* Size of input buffer in bytes, not including room
for EOB
         * characters.
         */
        yy_size_t yy_buf_size;

        /* Number of characters read into yy_ch_buf, not
including EOB
         * characters.
         */
        int yy_n_chars;

        /* Whether we "own" the buffer - i.e., we know we
created it,
         * and can realloc() it to grow it, and should
free() it to
         * delete it.
         */
        int yy_is_our_buffer;

        /* Whether this is an "interactive" input source; if
so, and
         * if we're using stdio for input, then we want to
use getc()
         * instead of fread(), to make sure we stop fetching
input after
         * each newline.
         */
        int yy_is_interactive;

        /* Whether we're considered to be at the beginning
of a line.
         * If so, '^' rules will be active on the next
match, otherwise
         * not.
         */
        int yy_at_bol;

        /* Whether to try to fill the input buffer when we
reach the
         * end of it.
         */
        int yy_fill_buffer;

        int yy_buffer_status;
#define YY_BUFFER_NEW 0
#define YY_BUFFER_NORMAL 1
        /* When an EOF's been seen but there's still some
text to process
         * then we mark the buffer as YY_EOF_PENDING, to
indicate that we
         * shouldn't try reading from the input source any
more.  We might
         * still have a bunch of tokens to match, though,
because of
         * possible backing-up.
         *
         * When we actually see the EOF, we change the
status to "new"
         * (via yyrestart()), so that the user can continue
scanning by
         * just pointing yyin at a new input file.
         */
#define YY_BUFFER_EOF_PENDING 2
        };

static YY_BUFFER_STATE yy_current_buffer = 0;

/* We provide macros for accessing buffer states in case in
the
 * future we want to put the buffer states in a more general
 * "scanner state".
 */
#define YY_CURRENT_BUFFER yy_current_buffer


/* yy_hold_char holds the character lost when yytext is
formed. */
static char yy_hold_char;

static int yy_n_chars;          /* number of characters read
into yy_ch_buf */


int yyleng;

/* Points to current character in buffer. */
static char *yy_c_buf_p = (char *) 0;
static int yy_init = 1;         /* whether we need to
initialize */
static int yy_start = 0;        /* start state number */

/* Flag which is used to allow yywrap()'s to do buffer
switches
 * instead of setting up a fresh yyin.  A bit of a hack ...
 */
static int yy_did_buffer_switch_on_eof;

void yyrestart YY_PROTO(( FILE *input_file ));

void yy_switch_to_buffer YY_PROTO(( YY_BUFFER_STATE
new_buffer ));
void yy_load_buffer_state YY_PROTO(( void ));
YY_BUFFER_STATE yy_create_buffer YY_PROTO(( FILE *file, int
size ));
void yy_delete_buffer YY_PROTO(( YY_BUFFER_STATE b ));
void yy_init_buffer YY_PROTO(( YY_BUFFER_STATE b, FILE *file
));
void yy_flush_buffer YY_PROTO(( YY_BUFFER_STATE b ));
#define YY_FLUSH_BUFFER yy_flush_buffer( yy_current_buffer )

YY_BUFFER_STATE yy_scan_buffer YY_PROTO(( char *base,
yy_size_t size ));
YY_BUFFER_STATE yy_scan_string YY_PROTO(( yyconst char
*yy_str ));
YY_BUFFER_STATE yy_scan_bytes YY_PROTO(( yyconst char
*bytes, int len ));

static void *yy_flex_alloc YY_PROTO(( yy_size_t ));
static void *yy_flex_realloc YY_PROTO(( void *, yy_size_t
));
static void yy_flex_free YY_PROTO(( void * ));

#define yy_new_buffer yy_create_buffer

#define yy_set_interactive(is_interactive) \
        { \
        if ( ! yy_current_buffer ) \
                yy_current_buffer = yy_create_buffer( yyin,
YY_BUF_SIZE ); \
        yy_current_buffer->yy_is_interactive =
is_interactive; \
        }

#define yy_set_bol(at_bol) \
        { \
        if ( ! yy_current_buffer ) \
                yy_current_buffer = yy_create_buffer( yyin,
YY_BUF_SIZE ); \
        yy_current_buffer->yy_at_bol = at_bol; \
        }

#define YY_AT_BOL() (yy_current_buffer->yy_at_bol)

typedef unsigned char YY_CHAR;
FILE *yyin = (FILE *) 0, *yyout = (FILE *) 0;
typedef int yy_state_type;
extern char *yytext;
#define yytext_ptr yytext

static yy_state_type yy_get_previous_state YY_PROTO(( void
));
static yy_state_type yy_try_NUL_trans YY_PROTO((
yy_state_type current_state ));
static int yy_get_next_buffer YY_PROTO(( void ));
static void yy_fatal_error YY_PROTO(( yyconst char msg[] ));

/* Done after the current pattern has been matched and
before the
 * corresponding action - sets up yytext.
 */
#define YY_DO_BEFORE_ACTION \
        yytext_ptr = yy_bp; \
        yyleng = (int) (yy_cp - yy_bp); \
        yy_hold_char = *yy_cp; \
        *yy_cp = '\0'; \
        yy_c_buf_p = yy_cp;

#define YY_NUM_RULES 64
#define YY_END_OF_BUFFER 65
static yyconst short int yy_accept[596] =
    {   0,
        0,    0,    0,    0,    0,    0,    0,    0,   
0,    0,
       32,   32,    0,    0,    0,    0,   55,   55,   65,  
63,
       63,   43,   46,    7,   35,   63,   44,   21,   22,  
25,
       63,   63,   61,   24,   26,   23,   40,   63,   41,  
35,
       35,   35,   35,   35,    6,   20,   52,   52,   63,  
35,
       35,    8,    8,    8,    8,    8,   64,   12,   39,  
39,
       39,   37,   39,   33,   32,   33,   31,   50,   48,  
47,
       50,   45,   55,   57,   56,   53,    7,   35,   
1,    2,
       61,   54,   60,   61,   42,   35,   35,   35,   35,  
35,
       52,   52,    3,   35,   35,    9,    9,    9,   
9,    9,

        9,   12,    0,    0,    0,    0,   38,   37,    0,  
37,
       37,   37,    0,    0,    0,   32,   32,    0,  
31,    0,
       49,   51,   55,   57,   56,   58,   56,   59,   53,  
60,
       60,   35,   35,    0,   34,    0,   35,   35,   52,  
35,
       35,    9,    9,    9,    9,   15,    9,    9,   
9,    0,
        0,    0,   38,   37,   37,    0,   36,    0,   
0,    0,
        0,   32,   32,    0,   30,    0,    0,   35,  
29,    0,
       35,   35,   35,   35,    9,    9,    9,    9,   
9,    9,
        9,    0,    0,    0,    0,    0,    0,    0,   
0,    0,
        0,    0,   35,    0,    0,   35,   35,   35,    9,  
17,

       16,    9,    9,    9,    9,   11,    0,    0,   
0,    0,



----------------------------------------------------------------------

Comment By: Fred W Kilner Genius (stupidfred)
Date: 2001-08-24 10:11

Message:
Logged In: YES 
user_id=306965

How do I upload files? I don't see a spot to do that.

I went to the ftp.sorceforge.net but didn't see an upload
directory.

Hmmm. I could try putting file on my ucsc webpage if you
don't have an
upload spot.

-Fred


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-24 09:39

Message:
Logged In: NO 

Ok if I log in with my password do I get to upload files..
Lets see!

I'm trying to upload a tar'd version of what I compiled for
cscope and
flex along with captued text showing commands I entered and
a few
other things.

I made a quick attempt at editing  configure  to make it
chose flex nomatter what but it didn't work. I did try the
--with-flex option before
and it didn't help.

In the tar'd up cscope is a file
A_COMPILE_ATTEMPT_WITH_OUTPUT.T

The current executable of cscope started getting segfaults
which is why
I wanted to have the source so I could compile it with debug
options and
use gdb if the problem didn't go away. I ended up just
filtering my file
list that it scans and that fixed it.

I use cscope with a big forth code source tree (openboot) so
I need to give it the list of files and then scan for just
text and that works great! for finding stuff.

Thanks
-Fred

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-24 05:23

Message:
Logged In: YES 
user_id=27517

You may have to convince it to really use flex. In order to
do that, it may be necessary to remove that "(cached)"
information produced by earlier "./configure" runs:

	make distclean
	./configure --with-flex

should help.

To see what the problem with the lex-generated scanner.c is,
I may need a copy of it. Esp. the sections close to where
the error messages were reported by the compiler (around
lines 623 and 919 of scanner.c). Either mail them or Upload
them to this bugreport form.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=454678&group_id=4664

Bugs item #453466, was opened at 2001-08-20 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Satya Nemana (satyan)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: top lines invisible but still selectable

Initial Comment:
Environment: Windows 2K Professional 1-2 Pentium CPU 
on Dell Systems. Using CSCOPE 15.3 built with GNU 
gcc/g++ tools downloaded from CYGWIN 5.0 for Windows.

If I invoke cscope session on the same 15.3 src 
directory and search for 'getline', then it displays 
all lines that contain 'getline' and I can select any 
of them for example 0 through 9 and get into vi.

Functionally it works OK. But some of the lines in the 
top part of cscope window are not visible. In this 
case on cscope15.3/src, if I search for getline, then 
the lines 0 to 6 are not visible. I have added a 
snapshot of the screen dump as an enclosure with this.

This problem is not only for searching as illustrated 
above, but also occurs sometimes if I try to do "Find 
this C symbol:", "Find this global definition:" etc. 
Typically it happens, when the resulting buffers 
displayed in top cscope window overflows beyond 
certian large buffer lengths.

Selecting 0 to 6 in above example, brings up the vi 
session. It means functioanally it works. Only the 
displaying lines are missing. Please note that these 
top invisible 6 lines appear as blabk lines, which 
means the 1st visible line (which is 7) is located in 
8th row and the all the 7 top rows are blank lines.

I don't know if it happens on Solaris with our 
version. I would like to check it and let you know.


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 11:37

Message:
Logged In: YES 
user_id=27517

I suspect the real problem is that CYGWIN is trying to be
overly clever, here.

cscope is supposed to already deal with this issue correctly
--- all reads of filenames are done in text mode, but all
files cscopes writes (including those of the cscope.out
file) are in binary mode. Without those changes, porting
cscope to DJGPP would never have been possible.

But IIRC, Cygwin has a really boneheaded idea that it should
be doing DOS<->UNIX textfile conversion behind the scenes,
too. For a program carefully ported to non-Unix filesystems
already, this transformation breaks it instead of fixing
anything.

The solution might be to force Cygwin to interpret these
sourcefiles as binary mountpoints. 

----------------------------------------------------------------------

Comment By: Satya Nemana (satyan)
Date: 2001-08-21 11:25

Message:
Logged In: YES 
user_id=302967

Broeker,
Congrats. you nailed the problem right on its head. All the 
cscope sources came up in DOS mode with each line ending 
with \r\n in stead of a just \n whereas system headers are 
not in dos format.

If the file is in DOS mode, then cscope shows up invisible 
or blank lines. In stead of expecting the user to convert 
all files into non-dos mode, it is better for cscope to 
treat them in same way, by fixing it in cscope.exe.

In my example, what ever are displayed are system headers, 
which are not in DOS mode (line terminates with a \n) and 
hence these lines are visible. For example, I could not see 
the command.c entries for getline search. I could see them 
again, as soon as I removed the \r before \n.

Once I converted the command.c file into non-dos mode (as 
indicated below) by removing the \r before \n, then these 
lines became visible.

I normally use vim.exe, which comes with GNU in CYGWIN, and 
is linked to vi.exe, so that vi is same as vim. To convert 
into dos mode actually, I copied stdio.h into a local 
command.c and did a .r oldcommand.c and removed the actual 
stdio.h related lines, so that file format is preserved.

Summary is that this can be fixed in cscope somehow by 
treating \r\n specially and converting into \n. Please let 
me know, if I can fix it here and send it for your review. 
I will wait for your suggestion. Thanks in advance.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 03:25

Message:
Logged In: YES 
user_id=27517

More likely than not, this is a Curses-related problem. I
had lots of problems with the DOS version of curses, too. 

Does the display come up correctly again if you force a
redraw (by typing Ctrl-L)?  

Did you try it with a less more traditional Screen size? The
screenshot you uploaded seems to be from a session with
considerably more than 25 lines.

And yet another idea: reproducing your example search for
symbol "getline", I only find 7 references (numbered 0 to
6), all contained in the cscope sources. The ones still
visible in your screenshot are from system headers. This
*may* be part of the problem, or a sign of some difference
between local source files and system headers that causes
it.  It just might be a DOS-style line endings problem, e.g.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Bugs item #453466, was opened at 2001-08-20 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Satya Nemana (satyan)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: top lines invisible but still selectable

Initial Comment:
Environment: Windows 2K Professional 1-2 Pentium CPU 
on Dell Systems. Using CSCOPE 15.3 built with GNU 
gcc/g++ tools downloaded from CYGWIN 5.0 for Windows.

If I invoke cscope session on the same 15.3 src 
directory and search for 'getline', then it displays 
all lines that contain 'getline' and I can select any 
of them for example 0 through 9 and get into vi.

Functionally it works OK. But some of the lines in the 
top part of cscope window are not visible. In this 
case on cscope15.3/src, if I search for getline, then 
the lines 0 to 6 are not visible. I have added a 
snapshot of the screen dump as an enclosure with this.

This problem is not only for searching as illustrated 
above, but also occurs sometimes if I try to do "Find 
this C symbol:", "Find this global definition:" etc. 
Typically it happens, when the resulting buffers 
displayed in top cscope window overflows beyond 
certian large buffer lengths.

Selecting 0 to 6 in above example, brings up the vi 
session. It means functioanally it works. Only the 
displaying lines are missing. Please note that these 
top invisible 6 lines appear as blabk lines, which 
means the 1st visible line (which is 7) is located in 
8th row and the all the 7 top rows are blank lines.

I don't know if it happens on Solaris with our 
version. I would like to check it and let you know.


----------------------------------------------------------------------

>Comment By: Satya Nemana (satyan)
Date: 2001-08-21 12:46

Message:
Logged In: YES 
user_id=302967

No. This is nothing to do with CYGWIN. It is just the file 
format. I could see that from the octal file dump using the 
od command, as illsutrated below. With this octal dump, I 
can prove that if the file contains \r\n at EOL, then this 
problem occurs. When I untarred your cscope15.3.tar.gz, 
these files like src/command.c are created in DOS mode.

Once I converted into unix mode by replacing \r\n into \n 
at EOL, then the problem went away. Another way of doing 
this conversion is that vim support :set fileformat=dos and 
when I quit with :wq, the file will be saved in unix mode.

Before conversion:
$ od -c ccommand.c
0000000   /   *   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
0000020   =   =   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
*
0000100   =   =   =   =   =   =   =   =   =   =   =   =   
=  \r  \n
0000120   C   o   p   y   r   i   g   h   t       (   
c   )       1   9

After conversion:
$ od -c command.c
0000000   /   *   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
0000020   =   =   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
*
0000100   =   =   =   =   =   =   =   =   =   =   =   =   
=  \n       C
0000120   o   p   y   r   i   g   h   t       (   
c   )       1   9   9

I may be wrong, but I still think, this could be fixed in 
cscope.exe by trimming the last but one char, if it finds 
\r\n at EOL. I will take a look into it and send the fix.

As far as vim.exe is concerned, it is smart enough to 
distinguish between dos and unix modes and make vi work 
sameway, so that user do not see these \r\n specially. It 
displays the file mode at the bottom line of vi session. It 
also provides conversions by the :set command. But all this 
is irrelavant to the current problem. cscope can not 
display the lines that end with \r\n, which can be fixed in 
cscope, I believe. Sorry, if I am misleading by any chance.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 11:37

Message:
Logged In: YES 
user_id=27517

I suspect the real problem is that CYGWIN is trying to be
overly clever, here.

cscope is supposed to already deal with this issue correctly
--- all reads of filenames are done in text mode, but all
files cscopes writes (including those of the cscope.out
file) are in binary mode. Without those changes, porting
cscope to DJGPP would never have been possible.

But IIRC, Cygwin has a really boneheaded idea that it should
be doing DOS<->UNIX textfile conversion behind the scenes,
too. For a program carefully ported to non-Unix filesystems
already, this transformation breaks it instead of fixing
anything.

The solution might be to force Cygwin to interpret these
sourcefiles as binary mountpoints. 

----------------------------------------------------------------------

Comment By: Satya Nemana (satyan)
Date: 2001-08-21 11:25

Message:
Logged In: YES 
user_id=302967

Broeker,
Congrats. you nailed the problem right on its head. All the 
cscope sources came up in DOS mode with each line ending 
with \r\n in stead of a just \n whereas system headers are 
not in dos format.

If the file is in DOS mode, then cscope shows up invisible 
or blank lines. In stead of expecting the user to convert 
all files into non-dos mode, it is better for cscope to 
treat them in same way, by fixing it in cscope.exe.

In my example, what ever are displayed are system headers, 
which are not in DOS mode (line terminates with a \n) and 
hence these lines are visible. For example, I could not see 
the command.c entries for getline search. I could see them 
again, as soon as I removed the \r before \n.

Once I converted the command.c file into non-dos mode (as 
indicated below) by removing the \r before \n, then these 
lines became visible.

I normally use vim.exe, which comes with GNU in CYGWIN, and 
is linked to vi.exe, so that vi is same as vim. To convert 
into dos mode actually, I copied stdio.h into a local 
command.c and did a .r oldcommand.c and removed the actual 
stdio.h related lines, so that file format is preserved.

Summary is that this can be fixed in cscope somehow by 
treating \r\n specially and converting into \n. Please let 
me know, if I can fix it here and send it for your review. 
I will wait for your suggestion. Thanks in advance.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 03:25

Message:
Logged In: YES 
user_id=27517

More likely than not, this is a Curses-related problem. I
had lots of problems with the DOS version of curses, too. 

Does the display come up correctly again if you force a
redraw (by typing Ctrl-L)?  

Did you try it with a less more traditional Screen size? The
screenshot you uploaded seems to be from a session with
considerably more than 25 lines.

And yet another idea: reproducing your example search for
symbol "getline", I only find 7 references (numbered 0 to
6), all contained in the cscope sources. The ones still
visible in your screenshot are from system headers. This
*may* be part of the problem, or a sign of some difference
between local source files and system headers that causes
it.  It just might be a DOS-style line endings problem, e.g.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Bugs item #453466, was opened at 2001-08-20 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Satya Nemana (satyan)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: top lines invisible but still selectable

Initial Comment:
Environment: Windows 2K Professional 1-2 Pentium CPU 
on Dell Systems. Using CSCOPE 15.3 built with GNU 
gcc/g++ tools downloaded from CYGWIN 5.0 for Windows.

If I invoke cscope session on the same 15.3 src 
directory and search for 'getline', then it displays 
all lines that contain 'getline' and I can select any 
of them for example 0 through 9 and get into vi.

Functionally it works OK. But some of the lines in the 
top part of cscope window are not visible. In this 
case on cscope15.3/src, if I search for getline, then 
the lines 0 to 6 are not visible. I have added a 
snapshot of the screen dump as an enclosure with this.

This problem is not only for searching as illustrated 
above, but also occurs sometimes if I try to do "Find 
this C symbol:", "Find this global definition:" etc. 
Typically it happens, when the resulting buffers 
displayed in top cscope window overflows beyond 
certian large buffer lengths.

Selecting 0 to 6 in above example, brings up the vi 
session. It means functioanally it works. Only the 
displaying lines are missing. Please note that these 
top invisible 6 lines appear as blabk lines, which 
means the 1st visible line (which is 7) is located in 
8th row and the all the 7 top rows are blank lines.

I don't know if it happens on Solaris with our 
version. I would like to check it and let you know.


----------------------------------------------------------------------

>Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-22 04:05

Message:
Logged In: YES 
user_id=27517

You shouldn't dismiss Cygwin's role so quickly. Guess what
runtime environment your 'tar' and your 'od' are using ---
yes, it's the same Cygwin that your freshly compiled cscope
uses, probably.

If it weren't for over-smart Cygwin, the files extracted by
"tar" wouldn't have been in DOS textfile format, to begin
with.

And the way cscope opens its files, it *should*
automatically cut out the CR in DOS-style linebreaks as it
reads a source file. That's how
text mode for fopen() is defined.  If it doesn't, that's a
grave misbehaviour of Cygwin. There should never be
DOS-style linebreaks in cscope.out (It's written in binary
mode), but from the symptoms you describe, there are.  And
that's the real problem.

Please check your 'mount' options and the Cygwin docs about
this.
And check the generated cscope.out file if you run cscope -k
upon a single source file that has DOS-style CRLF
linebreaks. Does cscope.out have CRLF ones, too?

----------------------------------------------------------------------

Comment By: Satya Nemana (satyan)
Date: 2001-08-21 12:46

Message:
Logged In: YES 
user_id=302967

No. This is nothing to do with CYGWIN. It is just the file 
format. I could see that from the octal file dump using the 
od command, as illsutrated below. With this octal dump, I 
can prove that if the file contains \r\n at EOL, then this 
problem occurs. When I untarred your cscope15.3.tar.gz, 
these files like src/command.c are created in DOS mode.

Once I converted into unix mode by replacing \r\n into \n 
at EOL, then the problem went away. Another way of doing 
this conversion is that vim support :set fileformat=dos and 
when I quit with :wq, the file will be saved in unix mode.

Before conversion:
$ od -c ccommand.c
0000000   /   *   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
0000020   =   =   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
*
0000100   =   =   =   =   =   =   =   =   =   =   =   =   
=  \r  \n
0000120   C   o   p   y   r   i   g   h   t       (   
c   )       1   9

After conversion:
$ od -c command.c
0000000   /   *   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
0000020   =   =   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
*
0000100   =   =   =   =   =   =   =   =   =   =   =   =   
=  \n       C
0000120   o   p   y   r   i   g   h   t       (   
c   )       1   9   9

I may be wrong, but I still think, this could be fixed in 
cscope.exe by trimming the last but one char, if it finds 
\r\n at EOL. I will take a look into it and send the fix.

As far as vim.exe is concerned, it is smart enough to 
distinguish between dos and unix modes and make vi work 
sameway, so that user do not see these \r\n specially. It 
displays the file mode at the bottom line of vi session. It 
also provides conversions by the :set command. But all this 
is irrelavant to the current problem. cscope can not 
display the lines that end with \r\n, which can be fixed in 
cscope, I believe. Sorry, if I am misleading by any chance.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 11:37

Message:
Logged In: YES 
user_id=27517

I suspect the real problem is that CYGWIN is trying to be
overly clever, here.

cscope is supposed to already deal with this issue correctly
--- all reads of filenames are done in text mode, but all
files cscopes writes (including those of the cscope.out
file) are in binary mode. Without those changes, porting
cscope to DJGPP would never have been possible.

But IIRC, Cygwin has a really boneheaded idea that it should
be doing DOS<->UNIX textfile conversion behind the scenes,
too. For a program carefully ported to non-Unix filesystems
already, this transformation breaks it instead of fixing
anything.

The solution might be to force Cygwin to interpret these
sourcefiles as binary mountpoints. 

----------------------------------------------------------------------

Comment By: Satya Nemana (satyan)
Date: 2001-08-21 11:25

Message:
Logged In: YES 
user_id=302967

Broeker,
Congrats. you nailed the problem right on its head. All the 
cscope sources came up in DOS mode with each line ending 
with \r\n in stead of a just \n whereas system headers are 
not in dos format.

If the file is in DOS mode, then cscope shows up invisible 
or blank lines. In stead of expecting the user to convert 
all files into non-dos mode, it is better for cscope to 
treat them in same way, by fixing it in cscope.exe.

In my example, what ever are displayed are system headers, 
which are not in DOS mode (line terminates with a \n) and 
hence these lines are visible. For example, I could not see 
the command.c entries for getline search. I could see them 
again, as soon as I removed the \r before \n.

Once I converted the command.c file into non-dos mode (as 
indicated below) by removing the \r before \n, then these 
lines became visible.

I normally use vim.exe, which comes with GNU in CYGWIN, and 
is linked to vi.exe, so that vi is same as vim. To convert 
into dos mode actually, I copied stdio.h into a local 
command.c and did a .r oldcommand.c and removed the actual 
stdio.h related lines, so that file format is preserved.

Summary is that this can be fixed in cscope somehow by 
treating \r\n specially and converting into \n. Please let 
me know, if I can fix it here and send it for your review. 
I will wait for your suggestion. Thanks in advance.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 03:25

Message:
Logged In: YES 
user_id=27517

More likely than not, this is a Curses-related problem. I
had lots of problems with the DOS version of curses, too. 

Does the display come up correctly again if you force a
redraw (by typing Ctrl-L)?  

Did you try it with a less more traditional Screen size? The
screenshot you uploaded seems to be from a session with
considerably more than 25 lines.

And yet another idea: reproducing your example search for
symbol "getline", I only find 7 references (numbered 0 to
6), all contained in the cscope sources. The ones still
visible in your screenshot are from system headers. This
*may* be part of the problem, or a sign of some difference
between local source files and system headers that causes
it.  It just might be a DOS-style line endings problem, e.g.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Bugs item #453466, was opened at 2001-08-20 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Satya Nemana (satyan)
Assigned to: Hans-Bernhard Broeker (broeker)
Summary: top lines invisible but still selectable

Initial Comment:
Environment: Windows 2K Professional 1-2 Pentium CPU 
on Dell Systems. Using CSCOPE 15.3 built with GNU 
gcc/g++ tools downloaded from CYGWIN 5.0 for Windows.

If I invoke cscope session on the same 15.3 src 
directory and search for 'getline', then it displays 
all lines that contain 'getline' and I can select any 
of them for example 0 through 9 and get into vi.

Functionally it works OK. But some of the lines in the 
top part of cscope window are not visible. In this 
case on cscope15.3/src, if I search for getline, then 
the lines 0 to 6 are not visible. I have added a 
snapshot of the screen dump as an enclosure with this.

This problem is not only for searching as illustrated 
above, but also occurs sometimes if I try to do "Find 
this C symbol:", "Find this global definition:" etc. 
Typically it happens, when the resulting buffers 
displayed in top cscope window overflows beyond 
certian large buffer lengths.

Selecting 0 to 6 in above example, brings up the vi 
session. It means functioanally it works. Only the 
displaying lines are missing. Please note that these 
top invisible 6 lines appear as blabk lines, which 
means the 1st visible line (which is 7) is located in 
8th row and the all the 7 top rows are blank lines.

I don't know if it happens on Solaris with our 
version. I would like to check it and let you know.


----------------------------------------------------------------------

>Comment By: Satya Nemana (satyan)
Date: 2001-08-22 17:05

Message:
Logged In: YES 
user_id=302967

I take this as an update. II added replies to all your 
questsions below. I was not aware of this magic done by 
Cygwin internally, which I tend to agree upon.

But onething is for sure that this conversion from dos to 
unix mode, brings up the invisible lines to display, 
makeing them visible again. It works like a temporary fix. 
I need to write a little a script to do this conversion 
before I start using the cscope on Cygwin on Windows.

Surprisingly, I noticed that if I "Find a C symbol" 
for "main" in cscope src using cscope, then main.c dislays 
visible lines, eventhough main.c is in DOS mode ie \r\n at 
EOL. So my earlier theory of not nailing down the problem 
to DOS/UNIX ormat being responsible for invisible lines is 
not correct, as this "main" case makes an exception already.

And also, cscope.out is not fully in DOS/UNIX mode, whether 
I run it with -k or without -k or single files or many 
files, because some lines in cscope.out terminate with \n 
and some others with \r\n as follows:

0000000   c   s   c   o   p   e       1   5       $   H   
O   M   E   /
0000020   s   a   t   y   a   /   c   s   c   o   p   e   
1   5   .   3
0000040   /   c   s   c   o   p   e   -   1   5   .   
3   /   s   r   c
0000060                                                     
          0
0000100   0   0   0   4   5   1   0   3   4  \n  \t   @   
a   l   l   o
0000120   c   .   c  \n  \n   3   5     002  \n  \t   ~   < 
241   d   i
0000140   o   .   h  \n   >  \r  \n  \n   3   6     002  
\n  \t   ~   <
0000160 241   r 232   g   .   h  \n   >  \r  \n  \n   3   
7     002  \n
0000200  \t   ~   "   l   i   b 277   r   y   .   h  
\n   "  \r  \n  \n
0000220   3   8     002  \n  \t   ~   "   g   l   o   b 
256   .   h  \n
0000240   "  \r  \n  \n   4   0     030 005   c 332 
241      \n  \t   g


mount options for cygwin already show up as binmode as 
follows:

$ mount
C:\cygwin\bin on /usr/bin type system (binmode)
C:\cygwin\lib on /usr/lib type system (binmode)
C:\cygwin on / type system (binmode)
c: on /cygdrive/c type user (binmode,noumount)
e: on /cygdrive/e type user (binmode,noumount)
j: on /cygdrive/j type user (binmode,noumount)
r: on /cygdrive/r type user (binmode,noumount)
s: on /cygdrive/s type user (binmode,noumount)
z: on /cygdrive/z type user (binmode,noumount)

I agree with you that tar untars all files and puts them 
into dos mode by default, eventhough the real files inside 
the tar, as I could see on a solaris system, do not contain 
\r\n. It is the cygwin that does some magic to make the 
files appear or covert into dos mode by tar command.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-22 04:05

Message:
Logged In: YES 
user_id=27517

You shouldn't dismiss Cygwin's role so quickly. Guess what
runtime environment your 'tar' and your 'od' are using ---
yes, it's the same Cygwin that your freshly compiled cscope
uses, probably.

If it weren't for over-smart Cygwin, the files extracted by
"tar" wouldn't have been in DOS textfile format, to begin
with.

And the way cscope opens its files, it *should*
automatically cut out the CR in DOS-style linebreaks as it
reads a source file. That's how
text mode for fopen() is defined.  If it doesn't, that's a
grave misbehaviour of Cygwin. There should never be
DOS-style linebreaks in cscope.out (It's written in binary
mode), but from the symptoms you describe, there are.  And
that's the real problem.

Please check your 'mount' options and the Cygwin docs about
this.
And check the generated cscope.out file if you run cscope -k
upon a single source file that has DOS-style CRLF
linebreaks. Does cscope.out have CRLF ones, too?

----------------------------------------------------------------------

Comment By: Satya Nemana (satyan)
Date: 2001-08-21 12:46

Message:
Logged In: YES 
user_id=302967

No. This is nothing to do with CYGWIN. It is just the file 
format. I could see that from the octal file dump using the 
od command, as illsutrated below. With this octal dump, I 
can prove that if the file contains \r\n at EOL, then this 
problem occurs. When I untarred your cscope15.3.tar.gz, 
these files like src/command.c are created in DOS mode.

Once I converted into unix mode by replacing \r\n into \n 
at EOL, then the problem went away. Another way of doing 
this conversion is that vim support :set fileformat=dos and 
when I quit with :wq, the file will be saved in unix mode.

Before conversion:
$ od -c ccommand.c
0000000   /   *   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
0000020   =   =   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
*
0000100   =   =   =   =   =   =   =   =   =   =   =   =   
=  \r  \n
0000120   C   o   p   y   r   i   g   h   t       (   
c   )       1   9

After conversion:
$ od -c command.c
0000000   /   *   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
0000020   =   =   =   =   =   =   =   =   =   =   =   =   
=   =   =   =
*
0000100   =   =   =   =   =   =   =   =   =   =   =   =   
=  \n       C
0000120   o   p   y   r   i   g   h   t       (   
c   )       1   9   9

I may be wrong, but I still think, this could be fixed in 
cscope.exe by trimming the last but one char, if it finds 
\r\n at EOL. I will take a look into it and send the fix.

As far as vim.exe is concerned, it is smart enough to 
distinguish between dos and unix modes and make vi work 
sameway, so that user do not see these \r\n specially. It 
displays the file mode at the bottom line of vi session. It 
also provides conversions by the :set command. But all this 
is irrelavant to the current problem. cscope can not 
display the lines that end with \r\n, which can be fixed in 
cscope, I believe. Sorry, if I am misleading by any chance.

----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 11:37

Message:
Logged In: YES 
user_id=27517

I suspect the real problem is that CYGWIN is trying to be
overly clever, here.

cscope is supposed to already deal with this issue correctly
--- all reads of filenames are done in text mode, but all
files cscopes writes (including those of the cscope.out
file) are in binary mode. Without those changes, porting
cscope to DJGPP would never have been possible.

But IIRC, Cygwin has a really boneheaded idea that it should
be doing DOS<->UNIX textfile conversion behind the scenes,
too. For a program carefully ported to non-Unix filesystems
already, this transformation breaks it instead of fixing
anything.

The solution might be to force Cygwin to interpret these
sourcefiles as binary mountpoints. 

----------------------------------------------------------------------

Comment By: Satya Nemana (satyan)
Date: 2001-08-21 11:25

Message:
Logged In: YES 
user_id=302967

Broeker,
Congrats. you nailed the problem right on its head. All the 
cscope sources came up in DOS mode with each line ending 
with \r\n in stead of a just \n whereas system headers are 
not in dos format.

If the file is in DOS mode, then cscope shows up invisible 
or blank lines. In stead of expecting the user to convert 
all files into non-dos mode, it is better for cscope to 
treat them in same way, by fixing it in cscope.exe.

In my example, what ever are displayed are system headers, 
which are not in DOS mode (line terminates with a \n) and 
hence these lines are visible. For example, I could not see 
the command.c entries for getline search. I could see them 
again, as soon as I removed the \r before \n.

Once I converted the command.c file into non-dos mode (as 
indicated below) by removing the \r before \n, then these 
lines became visible.

I normally use vim.exe, which comes with GNU in CYGWIN, and 
is linked to vi.exe, so that vi is same as vim. To convert 
into dos mode actually, I copied stdio.h into a local 
command.c and did a .r oldcommand.c and removed the actual 
stdio.h related lines, so that file format is preserved.

Summary is that this can be fixed in cscope somehow by 
treating \r\n specially and converting into \n. Please let 
me know, if I can fix it here and send it for your review. 
I will wait for your suggestion. Thanks in advance.


----------------------------------------------------------------------

Comment By: Hans-Bernhard Broeker (broeker)
Date: 2001-08-21 03:25

Message:
Logged In: YES 
user_id=27517

More likely than not, this is a Curses-related problem. I
had lots of problems with the DOS version of curses, too. 

Does the display come up correctly again if you force a
redraw (by typing Ctrl-L)?  

Did you try it with a less more traditional Screen size? The
screenshot you uploaded seems to be from a session with
considerably more than 25 lines.

And yet another idea: reproducing your example search for
symbol "getline", I only find 7 references (numbered 0 to
6), all contained in the cscope sources. The ones still
visible in your screenshot are from system headers. This
*may* be part of the problem, or a sign of some difference
between local source files and system headers that causes
it.  It just might be a DOS-style line endings problem, e.g.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104664&aid=453466&group_id=4664