[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warning: "/usr/include/ncursesw" is unsafe for cross-compilation

From: Thomas Dickey
Subject: Re: Warning: "/usr/include/ncursesw" is unsafe for cross-compilation
Date: Sun, 14 Sep 2014 10:22:55 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Sep 14, 2014 at 03:57:04PM +0200, Joakim Tjernlund wrote:
> Thomas Dickey <address@hidden> wrote on 2014/09/13 23:52:52:
> > 
> > On Fri, Sep 12, 2014 at 09:52:10AM +0200, Joakim Tjernlund wrote:
> > > In Gentoo[1] one can see this warning when cross building ncurses with 
> > > unicode support:
> > >   cc1: warning: include location "/usr/include/ncursesw" is unsafe for 
> > > cross-compilation [-Wpoison-system-directories]
> > > This is because ncurses adds -I\${includedir} to CPPFLAGS, simply 
> > > removing 
> > 
> > Actually, the --includedir option is used to override the program's sense
> > of where the essential system headers are - if they are not in the default
> > location used by the compiler.
> --includedir is where the include files should be INSTALLED, not where system 
> headers are.
> > 
> > Setting the option to point to the default location - or as shown in the 
> > bug report,
> > to a redundant location - is pointless.
> not so, it is set to where Gentoo wants to have ncursesw headers to be 
> installed.

That's a nice goal, but it doesn't correspond to the way most applications
use subdirectories of includedir, and is a source of bug-reports.

Because ncurses can be installed on systems where it may/may not be the
default "curses" library, it provides (since 1995 - 7 years before Gentoo
started) a configure option for what Gentoo appears to be attempting:

        If you are installing ncurses on a system which contains another
        development version of curses, or which could be confused by the loader
        for another version, we recommend that you leave out the link to
        -lcurses.  The ncurses library is always available as -lncurses.
        Disabling overwrite also causes the ncurses header files to be
        installed into a subdirectory, e.g., /usr/local/include/ncurses,
        rather than the include directory.  This makes it simpler to avoid
        compile-time conflicts with other versions of curses.h

> Using that to search for include files is just plain wrong. The first time 
> you build ncurses there is no files there at all.

Building ncurses uses header files from the cross-compiler's compile-time
system - that's what includedir is normally (outside Gentoo's niche) used
> > For cross-compiling, there are some valid issues with the sample scripts 
> > which I use
> > for making packages.  However, there has been no feedback that I recall 
> > from any packager
> > regarding those scripts, so I have not discussed those issues (they're 
> > simply to-do items
> > on my list (>1500 items...).
> Ouch, that is some list

yes (I'll never run out, since it continues to grow).
> > > this makes it build
> > > without this warning.
> > 
> > sometimes.
> hmm, if there is some cross build fallout from removing includedir from 
> CPPFLAGS that would have
> to be fixed some other way.

probably.  Packagers with unusual requirements tend to write sed-scripts.

In a quick check of the package-scripts which I wrote for Debian and Fedora,
I don't see that I had to bend any rules.
> > 
> > > [1] https://bugs.gentoo.org/show_bug.cgi?id=522586
> > > 
> > >    Jocke
> > > 
> > > PS.
> > >     Why are there no proper releases of ncurses? I can just find a lot of 
> > > patches
> > 
> > I intend doing a regular release when I'm done with the MinGW port.
> > (Packagers can pick up the patches, of course - even Gentoo).
> Sure, but trying to understand what each change do is much harder when you 
> only got
> a patch containing many different changes.
> > 
> > >     Is the a public repo somewhere?
> > 
> > Someone keeps a git repository, as noted here:
> > 
> >    https://lists.gnu.org/archive/html/bug-ncurses/2010-07/msg00021.html
> This collects you patch files into one coherent src tree, much better than 
> loose patch files.
> It is not a replacement for a repo where one can follow each logical 
> change in a commit though.

sure - but unlike the finer-grained repo, what you get is what I've tested
for various combinations.

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]