Re: Default library and header search paths

> This depends on your sense of "interfere". It is true in the most
> basic sense in that installations cannot overwrite or remove base
> headers, and so cannot affect base system (re)builds. But in the
> situation I reference above, when headers for the same library exist
> both in base and elsewhere, bo golly, they *do* interfere with package
> builds.

So I'll concede that my definition of "interfere" probably differs
from that of yours.
When I compile software by hand which is pretty frequent, I know which
headers/libs I'm compiling against because it's well defined in my
build system.
Can installed software from ports/packages "interfere" with the base
system given the same file names?   I suppose so, but I seldom run
into that personally.
Given that everything is well defined for me, it's seldom a problem
that I'd be compiling against libs installed under /usr/local/lib vs
/lib.
This is mostly due to the order of inclusion of directories.

>
> >  - .. and probably most importantly, follows the defined unix
> > hierarchical conventions established in 97' (I think it was -- open to
> > being corrected).  FreeBSD has splintered from this ever so slightly,
> > but it's darn close enough.
>
> Those conventions depend on the notion of "vendor", which doesn't really
> apply to FOSS packages. I don't think anyone installs just the base system
> and then hand compiles everything else; everyone uses at least a few
> packages (in the narrow BSD sense) or ports. So unless your language is
> literal and legalistic to the extreme, these commonly used ports are just
> as much part of FreeBSD as the base.

I don't think your comment is in conflict with what I've stated.  I
entirely agree about FOSS not really giving a damn about hierarchical
standards.
The only thing I'd mention is that I'm not talking about FOSS and
instead am only talking about FreeBSD and the hierarchical standards
it itself has adopted.
Port maintainers should (do?) conform to those standards and they do
an excellent job at doing so.

> > For libs, just add /usr/local/lib to /etc/ld.so.conf.d/local.conf and
> > run ldconfig.
>
> But this only affects run time, doesn't it? For build time you still
> need to add the requisite -L options in one way or another. Correct me
> if I'm wrong.
>

You're not wrong and this is a side effect of me writing a response to
an email at 4am, after a US holiday, 10 sheets into the wind w/ an
alcohol induced coma!  Whoops!
I apologize for that confusion as what I wrote clearly isn't right.
You are correct in that it only applies to runtime.

> > Ultimately though, when I program in C on FreeBSD which is like nearly
> > all programming I do, my build system (make(1) for me), already has
> > everything defined.
>
> Can you expand this, please? Do you mean make(1) has the needed CFLAGS
> and LDFLAGS built in?
>

So to clarify I define the necessary CFLAGS and LDFLAGS in my build
environment; it's not built-in.
There's a couple of ways to accomplish this but I prefer to stick this
information within the Makefile itself.

Outside of using a Makefile you can stick this in your login .cshrc or
.bashrc or whatever shell you're using.
I don't use this method, but it's an option..I guess.

.. and lastly there's /etc/make.conf.  Again, I don't use this method
but it exists.  On occasion I might want to change global settings,
but seldom is this necessary.

> --
> Ian
>

~Paul

-- 
__________________

:(){ :|:& };: