Vincent Lefevre <vincent-opgr@vinc17.org> wrote:
> This is not that simple. IMHO, the main problem is that /usr/local is
> used as the default $prefix for most software, so that users install
> software there without knowing the consequences, in particular when
> they install libraries that have a different API from those provided
> by the vendor. Moreover this conflicts with systems of ports. For
> instance, under Mac OS X, MacPorts knows about these problems, but
> there's no clean way to say: let's only depend on /usr/{include,lib}
> (where the vendor's libraries are) and /opt/local/{include,lib} (the
> libraries installed by MacPorts), ignoring /usr/local (or having it
> at a lower precedence). According to POSIX, -I and -L should be able
> to do that, but this is incompatible with GCC's use of -I (due to its
> notion of system headers and the fact that /usr/local/include is seen
> as a system header path).
You are describing a problem that is well known since more than 20 years.
In the early times of UNIX, binaries have been in /bin. Later, someone permitted
all users to install private binaries, that might be of interest for onthers,
to
/usr/bin. If there was no cron job that checked for newer man pages if there was
an update in /usr/bin, we wold not even have documentation for those programs.
.... quoting a talk from Steve Bourne at the Sun User Group meeting in December
1990.
Some time later, /usr/bin was adopted by the system and the users invented
/usr/local as a replacement for /usr/bin. If nobody did stop this, this would
continue for ever.
Well, there was a plan to stop this in 1998 where the UNIX vendors introduced
/opt/<vendor>/*.
I am not sure whether a new option for a compiler will help. I believe that
this is something that needs to be understood by the platform vendors.
From my way of understanding POSIX, POSIX does not define path names but
just permits them to exist. Defining specific behavior for path names seems
to be outside the scope of POSIX.
There are platforms that spread the system inlcude files over more than one
path, so the default include path needs to be able to include more than
directory.
From your problem description, it seems as the cause for your problems is the
fact that some people install private include files into a directory that is
claimed to be a "system include dir" by the vendor. If this is true, how could
this mailing list help?
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
joerg.schilling@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
|