This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: should we search $prefix/include ?


Mark Mitchell <mark@codesourcery.com> writes:

> And, I agree with you that searching $prefix/include makes sense.  Would
> you mind preparing a patch, and beginning the testing cycle, so that we
> can know whether or not that works?

Which include directories are searched by default should match which lib
directories are searched by default.  Having to specify -I when you don't
need -L and vice versa is just confusing.

Having to specify -R or the equivalent when one doesn't need to specify -L
is also confusing, albeit less so.

We've had a local patch here at Stanford for some time that causes gcc to
search /usr/local/include and $prefix/include in that order before other
directories, and /usr/local/lib and $prefix/lib in that order for
libraries.  On one hand, it's been nice; on the other hand, we're starting
to get people complaining that they've built against shared libraries and
then their binaries don't run without LD_LIBRARY_PATH because they didn't
know to use -R or -Wl,-rpath or whatever other platform-specific magic was
needed.  Bleh.

(Our local patch is incredibly ugly and completely breaks the search path
used for cross-compiles, or whatever other reason $prefix/include/$target
is in the default path, so it's not really suitable for submission.  I'd
love to see this problem solved in the main gcc sources, though, although
we need more than what's just discussed; we want to search both /usr/local
*and* $prefix.)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]