Re: -I/usr/include (was: fixinc...)

[Russ Allbery <rra at stanford dot edu>]

Bruce Korb <bkorb@veritas.com> writes:
> Russ wrote:

>> It's *never* been correct to add -I/usr/include.  I'm amazed that there
>> are still packages making this mistake; like I said, I've hardly ever
>> run into a package with this problem.

> That seems a little strong.

I really don't think it is.

> If you ever run into a package that uses:

>    `guile-config compile`

> on the command line, you will run into it.

No, actually, I wouldn't.  This works fine for me, because my Guile
package is installed in a /usr/local equivalent.

Of course, if you're installing something as part of the operating system,
something that only an operating system packager needs to do, then you
have to adjust expectations in the package aimed at being installed in a
/usr/local equivalent.  That's just part of the work one has to do when
packaging software as part of a distribution rather than as an add-on
package like it was designed.

I see that Debian gets this wrong too, but that's definitely a bug in
Debian's Guile package, not in Guile.  It may be a missing feature in
Guile, but most of those packages were just never written with
installation as part of the operating system in mind.

> It turns out that package developers do not have complete control over
> their command line options.  :-}

It's easy enough to filter out /usr/include the way that gtk-config does;
that's probably the most robust solution.

Anyway, I don't think this is a gcc problem.  gcc has not allowed
-I/usr/include for as long as I've been working with gcc; the breakage is
just becoming more and more obvious with time as fixincludes has to do
more and more.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>