Re: Default library and header search paths
- Reply: Paul Procacci : "Re: Default library and header search paths"
- In reply to: Paul Procacci : "Re: Default library and header search paths"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 06 Jul 2025 16:55:36 UTC
On Sun, Jul 06, 2025 at 04:13:10AM -0400, Paul Procacci wrote:
> FreeBSD on the other hand is much more than just a kernel; it's also
> an entire userland. FreeBSD installs libs not included in the base
> system into different directories to maintain a clear separation
> between base system components and third-party software.
> This provides a plethora of benefits:
TBF, it also has some downsides :-P
When I build software from source there is an excellent chance that it
defaults to installation under /usr/local, both build time and run
time. But this cannot cleanly be done on FreeBSD because it conflicts
with ports and packages. So I have to use --prefix=/opt/${PACKAGE} or
something every time.
Granted this is just a minor nuisance and may be just an effect of
penguin systems being so widespread and packages wanting to simplify
the build experience as much as possible for that environment.
A more vexing problem is libraries which exist both in base and as
ports/packages, confusing builds. ncurses is -- perhaps appropriately --
the most prominent example. Another is libarchive which features in
my other recent thread here.
> - As an extension to the two items above, installed header files
> can't interfere with the base system.
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.
> - .. 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.
> 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.
> 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?
Many of the packages I compile need gmake, but this information would
still help.
--
Ian