[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:
--disable-overwrite
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.
> > 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>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature