public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/40442] Option -I and POSIX conformance (c99 utility)
Date: Mon, 15 Jun 2009 13:07:00 -0000 [thread overview]
Message-ID: <20090615130650.28426.qmail@sourceware.org> (raw)
In-Reply-To: <bug-40442-6373@http.gcc.gnu.org/bugzilla/>
------- Comment #5 from joseph at codesourcery dot com 2009-06-15 13:06 -------
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
> ------- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 -------
> (In reply to comment #3)
> > If you have modified the implementation (by putting headers/libraries in
> > standard directories where those headers/libraries were not provided by
> > the implementation in those versions in those directories, for example),
> > you are very definitely outside the scope of POSIX.
>
> I'm not sure I understand what you mean. But the existing practice is that
> additional headers/libraries (i.e. not those defined by the C standard)
> provided by the vendor are stored under /usr/{include,lib}. And I don't think
> this goes against POSIX. Concerning /usr/local, the FHS says:
>
> The /usr/local hierarchy is for use by the system administrator when
> installing software locally.
>
> So, it should be safe to add libraries there. And again, this is the existing
> practice.
It is not, however, safe to add libraries there that in any way conflict
with the libraries provided by the system in /usr (such as different
versions of the same libraries).
A POSIX-conforming system should have a POSIX conformance document that
explains the circumstances under which the claims of POSIX conformance are
made. Those circumstances will include restrictions on any modification
of system directories, such as limits on the contents of files in /etc for
the system to be conforming and limits on what may go in /usr/local if
some POSIX applications search that directory by default. This document
is nothing to do with GCC on its own; it has to be provided by the system
integrator and describes properties of the whole system. If the document
for the POSIX system you are using is inadequate, you should raise that
with the system integrator (and if necessary with whoever certified
conformance). And if POSIX does not render undefined options that have
the effect of changing internal configuration details of applications,
where those details have to be in a particular form for conformance (for
example, conformance requiring header and library directories in a
particular order), this is a bug in POSIX. -I or -L options pointing to
any of an implementation-defined set of system directories, or any
directory with duplicates of headers or libraries in system directories,
should be undefined behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
next prev parent reply other threads:[~2009-06-15 13:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-15 0:18 [Bug c/40442] New: " vincent at vinc17 dot org
2009-06-15 1:01 ` [Bug c/40442] " joseph at codesourcery dot com
2009-06-15 2:08 ` vincent at vinc17 dot org
2009-06-15 10:57 ` joseph at codesourcery dot com
2009-06-15 11:59 ` vincent at vinc17 dot org
2009-06-15 13:07 ` joseph at codesourcery dot com [this message]
2009-11-22 19:55 ` jsm28 at gcc dot gnu dot org
2009-11-23 4:51 ` vincent at vinc17 dot org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090615130650.28426.qmail@sourceware.org \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).