mutt: slight problem

mutt: slight problem

[Jean-Pierre Radley]

Mutt is my MUA; until today, I've been compiling it with Robert
Lipe's port of gcc for SCO OpenServer 5.

Having just now compiled and dejagnu-tested the 1.0 release of
egcs-gcc, the first program I tried to recompile was mutt
( ftp://ftp.cs.hmc.edu/pub/me/mutt/mutt-0.88e.tar.gz ).

All actions having to do with color or inverse video are
non-functional.  I'm using the same curses library under either
compilation.

I then recompiled xt and xc, communications programs which I
maintain.  They perform no color operations, but when compiled
against the same curses library, they do reverse-video just fine.


-- 
Jean-Pierre Radley   jpr@jpr.com   XC/XT Custodian   Sysop, CompuServe SCOForum

Re: mutt: slight problem

[Robert Lipe]

> Mutt is my MUA; until today, I've been compiling it with Robert
> Lipe's port of gcc for SCO OpenServer 5.

Thanx to you, Mutt is my MUA, too.   

> Having just now compiled and dejagnu-tested the 1.0 release of
> egcs-gcc, the first program I tried to recompile was mutt

I'm on egcs 1127 and am likely to remain so for at least a few
more days.

> All actions having to do with color or inverse video are
> non-functional.  I'm using the same curses library under either
> compilation.

Since I can't see this problem, we must be doing something 
different.   My Mutt uses color and inverse video just fine
and my screens look identical on either OpenServer or Linux.

Would you be using slang, ncurses, or the native curses?   I 
use only native.

For me, the generated config.h's for both "CC=/bin/cc -blf" configure"
and "configure" are identical.   Are they for you?    I suppose the
single most obvious place to look is for the entry:
/* Does your curses library support color? */
#define HAVE_COLOR 1

Does config.log tell you anything you didn't already know?


We can take it private if you like and just put the final solution 
back on the list.      I'll send you my generated config.h suitable
for diffing.

RJL

Re: mutt: slight problem

[Jean-Pierre Radley]

Robert Lipe telecommunicated (on 14Dec):
| > Mutt is my MUA; until today, I've been compiling it with Robert
| > Lipe's port of gcc for SCO OpenServer 5.
| 
| Thanx to you, Mutt is my MUA, too.   
| 
| > Having just now compiled and dejagnu-tested the 1.0 release of
| > egcs-gcc, the first program I tried to recompile was mutt
| 
| I'm on egcs 1127 and am likely to remain so for at least a few
| more days.
| 
| > All actions having to do with color or inverse video are
| > non-functional.  I'm using the same curses library under either
| > compilation.
| 
| Since I can't see this problem, we must be doing something 
| different.   My Mutt uses color and inverse video just fine
| and my screens look identical on either OpenServer or Linux.
| 
| Would you be using slang, ncurses, or the native curses?   I 
| use only native.

Native SCO curses library.

| For me, the generated config.h's for both "CC=/bin/cc -blf" configure"
| and "configure" are identical.   Are they for you?    I suppose the
| single most obvious place to look is for the entry:
| /* Does your curses library support color? */
| #define HAVE_COLOR 1

Yes, I have that too.

| Does config.log tell you anything you didn't already know?
 
Nope.

| 
| We can take it private if you like and just put the final solution 
| back on the list.      I'll send you my generated config.h suitable
| for diffing.

Which Robert did do, and the diffs were both trivial and unrelated to
terminals or colors.

-- 
Jean-Pierre Radley   jpr@jpr.com   XC/XT Custodian   Sysop, CompuServe SCOForum

Re: mutt: slight problem

[Jean-Pierre Radley]

Robert Lipe telecommunicated (on 14Dec):
| JPR wrote:
| > Mutt is my MUA; until today, I've been compiling it with Robert
| > Lipe's port of gcc for SCO OpenServer 5.
| 
| > Having just now compiled and dejagnu-tested the 1.0 release of
| > egcs-gcc, the first program I tried to recompile was mutt
| 
| We can take it private if you like and just put the final solution 
| back on the list.

I found my problem. Once upon a time, I had installed ncurses here, but
it never really worked.   Still left behind, though, were some files in
/usr/local/include: curses.h, term.h, termcap.h, and a few others.

I made those go bye-bye, now egcs-gcc doesn't trip on them, and my
mutt is again playing in living color.

-- 
Jean-Pierre Radley   jpr@jpr.com   XC/XT Custodian   Sysop, CompuServe SCOForum

"helpful" include additions, was: mutt: slight problem

[Robert Lipe]

> I found my problem. Once upon a time, I had installed ncurses here, but
> it never really worked.   Still left behind, though, were some files in
> /usr/local/include: curses.h, term.h, termcap.h, and a few others.
> 
> I made those go bye-bye, now egcs-gcc doesn't trip on them, and my
> mutt is again playing in living color.

This is becuase GCC and EGCS "helpfully" adds /usr/local/include and
a few other directories that are more sensible, since they're actually
populated with something during the 'make install'.

This feature has always done me more harm than help.   


Thanx for announcing the closure on this, JP.  I'll now delete 
the half-dozen builds I did while looking for the problem.

RJL

local_prefix a mistake

[Andrew Fitzgibbon]

Jean-Pierre Radley writes:
>I found my problem. Once upon a time, I had installed ncurses here, but
>it never really worked.   Still left behind, though, were some files in
>/usr/local/include: curses.h, term.h, termcap.h, and a few others.

It's a problem with local_prefix, which ought to be removed.  It's
undeniably useful, but the user should explicitly specify any -I flags
other than for /usr/include.

A.

-- 
Andrew Fitzgibbon, 			                  awf@robots.ox.ac.uk
Oxford Information Engineering Research Group                +44 01865 273127
	    <a href= http://www.robots.ox.ac.uk/~awf > Home Page </a>
			 "Never say there is no way"

Re: local_prefix a mistake

[H.J. Lu]

> 
> 
> Jean-Pierre Radley writes:
> >I found my problem. Once upon a time, I had installed ncurses here, but
> >it never really worked.   Still left behind, though, were some files in
> >/usr/local/include: curses.h, term.h, termcap.h, and a few others.
> 
> It's a problem with local_prefix, which ought to be removed.  It's
> undeniably useful, but the user should explicitly specify any -I flags
> other than for /usr/include.
> 

Too many things may assume it. Are you going to fix the Makefile
for them?

-- 
H.J. Lu (hjl@gnu.org)

Re: local_prefix a mistake

[Jean-Pierre Radley]

H.J. Lu telecommunicated (on 15Dec):
| > 
| > 
| > Jean-Pierre Radley writes:
| > >I found my problem. Once upon a time, I had installed ncurses here, but
| > >it never really worked.   Still left behind, though, were some files in
| > >/usr/local/include: curses.h, term.h, termcap.h, and a few others.
| > 
| > It's a problem with local_prefix, which ought to be removed.  It's
| > undeniably useful, but the user should explicitly specify any -I flags
| > other than for /usr/include.
| > 
| 
| Too many things may assume it. Are you going to fix the Makefile
| for them?

Nothing in mutt's Makefile refers to /usr/local/include.
My understanding is that gcc looks in that directory by default.

-- 
Jean-Pierre Radley   jpr@jpr.com   XC/XT Custodian   Sysop, CompuServe SCOForum

Re: local_prefix a mistake

[J. Kean Johnston]

On Mon, Dec 15, 1997 at 11:37:48AM +0000, Andrew Fitzgibbon wrote:
> It's a problem with local_prefix, which ought to be removed.  It's
> undeniably useful, but the user should explicitly specify any -I flags
> other than for /usr/include.
Not when the compiler is installed in /usr/local it shouldn't. The current
behaviour is correct and desirable. /usr/local is traditionally for add-on
stuff. You added on a vital VITAL development tool, your compiler. Why
would one assume if you are brave enough to use a replacement compiler
that you dont want to use replacement and addon libraries too?

If you REALLY wanna get around this, configure your egcs with --prefix=/usr
so that everything gets installed in /usr/bin, /usr/include etc. *THAT* is
when adding -I/usr/local/include would be The Wrong Thing.

Kean.

Re: local_prefix a mistake

[Andrew Fitzgibbon]

J. Kean Johnston writes:
>On Mon, Dec 15, 1997 at 11:37:48AM +0000, Andrew Fitzgibbon wrote:
>> It's a problem with local_prefix, which ought to be removed.  It's
>> undeniably useful, but the user should explicitly specify any -I flags
>> other than for /usr/include.

>Not when the compiler is installed in /usr/local it shouldn't. The current
>behaviour is correct and desirable. /usr/local is traditionally for add-on
>stuff. You added on a vital VITAL development tool, your compiler. Why
>would one assume if you are brave enough to use a replacement compiler
>that you dont want to use replacement and addon libraries too?

In that case, one should be allowed to specify local-prefix.  In fact, I
used to patch gcc so that multiple -local-prefix options could be supplied
but I stopped when I realised that even the default one was a bad idea.

Any Makefiles that depend on it will not work with other compilers.

>If you REALLY wanna get around this, configure your egcs with --prefix=/usr
>so that everything gets installed in /usr/bin, /usr/include etc. *THAT* is
>when adding -I/usr/local/include would be The Wrong Thing.

Therefore on linux the current behaviour is incorrect and (arguably)
undesirable.