Original commit message:
bsd.lib.mk: Do not include bsd.incs.mk for INTERNALLIB
f we're building an internal lib do not bother including bsd.incs.mk so we
will not install the headers.
This also "solves" a problem with pkgbase where a libXXX-development package
is created and due to how packages are created we add a dependency to a
libXXX package that doesn't exists.
If we're building an internal lib do not bother including bsd.incs.mk so we
will not install the headers.
This also "solves" a problem with pkgbase where a libXXX-development package
is created and due to how packages are created we add a dependency to a
libXXX package that doesn't exists.
Reported by: pizzamig
Reviewed by: pizzamig bapt emaste
Differential Revision: https://reviews.freebsd.org/D24166
Profiling library archives are part of the development environment; they
don't need to be in separate -profile packages.
(In fact we can probably just eliminate the _p.a archives assuming that
profiling will be done using hwpmc etc., but that is a change for later.)
Discussed with: bapt, manu
Sponsored by: The FreeBSD Foundation
arichardson has an actual fix for the same issue that this was working
around; given that we don't build with llvm today, go ahead and revert the
workaround in advance.
bsd.cpu.mk is included by bsd.init.mk before bsd.linker.mk, so it
was always setting the flag since LINKER_FEATURES wasn't defined.
Reported by: mhorne
Reviewed by: imp, mhorne
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23076
Diff partially stolen from CheriBSD; these bits need -Wl,-z,notext in order
to build in an LLVM world. They are needed for all flavors/sizes of MIPS.
This will eventually get fixed in LLVM, but it's unclear when.
Reported by: arichardson, emaste
Differential Revision: https://reviews.freebsd.org/D21696
GCC uses "dynamic" TLS models when -fpic or -fPIC is explicitly
specified on the command line (which is only true for shared libraries).
It uses "static" (or "exec") TLS models otherwise. In particular, GCC
does _not_ use dynamic TLS models when PIC is implicitly enabled (which
it is on MIPS), only if a PIC flag is explicitly provided.
llvm uses "dynamic" TLS models if PIC is enabled either via a PIC flag
or if it is implicily enabled (as on MIPS64). This means that llvm on
MIPS64 always uses "dynamic" TLS models. However, dynamic TLS models
do not work for static binaries and libraries as the __tls_get_addr
function they invoke is only defined in rtld.
Written by: jhb
Reviewed by: arichardson
Differential Revision: https://reviews.freebsd.org/D21699
The default package use to be FreeBSD-runtime but it should only contain
binaries and libs enough to boot to single user and repair the system, it
is also very handy to have a package that can be tranform to a small mfsroot.
So create a new package named FreeBSD-utilities and make it the default one.
Also move a few binaries and lib into this package when it make sense.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21506
Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).
With this change PIE objects have a .pieo extension and INTERNALLIB
libraries libXXX_pie.a.
MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as
they explicitly reference .a libraries in their Makefiles. These can
be addressed on an individual basis later. MK_PIE is also disabled for
rtld-elf because it is already position-independent using bespoke
Makefile rules.
Currently only dynamically linked binaries will be built as PIE.
Discussed with: dim
Reviewed by: kib
MFC after: 1 month
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18423
The linker's -z now flag sets the DF_BIND_NOW flag, which signals to the
runtime loader that all relocation processing should be performed at
process startup rather than on demand. In combination with lld's
default of enabling relro this causes the GOT to be made read-only when
the process starts, preventing straightforward GOT overwrite attacks.
Shawn Webb discovered a failure on HardenedBSD with BIND_NOW and ifunc
use, which resulted in my rtld fix in r340137. Add a BIND_NOW knob as
it is trivial to do so and is a useful ELF hardening feature. This
change is equivalent to HardenedBSD's but not identical as there are
other diffs/conflicts nearby.
Note that our ELF Tool Chain readelf does not currently decode the
DF_BIND_NOW flag - see PR232983.
Reviewed by: brooks
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17846
This paves the way for moving config files out of head/etc and into the
directories with the src.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D16406
Rtld is not compatible with SSP, and since we link libc_pic.a to rtld
to have the basic support like memory and string copy functions, we
have to both carefully limit libc use, and to provide the ssp support
shims. This change makes the libc use in rtld more straighforward but
still limited, and allows to remove the shims, to be done in the next
commit.
Submitted by: Luis Pires
Reviewed by: bdrewery, brooks
Differential revision: https://reviews.freebsd.org/D15283
Now that OBJS has grown an OBJS_SRCS_FILTER variable, use this variable
in the computation of BCOBJS and LLOBJS too. Also move BCOBJS and LLOBJS
computation to be next to the OBJS computation: this should both make
the parallel structure clearer and serve to remind people changing OBJS
that parallel changes are required in BCOBJS and LLOBJS.
A side effect of this change is that BCOBJS and LLOBJS will be available
even when LLVM_LINK has not been defined, but that seems like a positive
change: there's no reason we can't ask "what bitcode files would you
generate" just because we can't link those files together into a
complete bitcode representation of a binary or library.
Reviewed by: sjg
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D12701
We previously taught the build system how to create files like libfoo.bc,
but neglected to teach it about cleaning such files up. Rectify this now.
MFC after: 1 week
Sponsored by: DARPA, AFRL
Some makefiles do reachover builds.
In some cases it is convenient to list subdirs of the distribution
in SRCS.
It is not very convenient, or always even desirable to have corresponding
subdirs in .OBJDIR, so OBJS_SRCS_FILTER allows the makefile to choose.
The default value 'R' matches existing practice.
But a makefile can set OBJS_SRCS_FILTER= T (the R gets added by
bsd.init.mk) to avoid the need for subdirs in .OBJDIR
Differential Revision: https://reviews.freebsd.org/D12218
Reviewed by: bdrewery
The -S flag is currently ignored for builds since we filter through
tools/install.sh that is intended for both non-root and cross-builds.
Sponsored by: Dell EMC Isilon
X-MFC-With: r322565
- Include debug symbols in static libraries. This permits binaries
to include debug symbols for functions obtained from static libraries.
- Permit the C/C++ compiler flags added for MK_DEBUG_FILES to be
overridden by setting DEBUG_FILES_CFLAGS. Use this to limit the debug
information for llvm libraries and binaries.
Reviewed by: emaste
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D12025
Also disable this if NO_SAFE_LIBINSTALL is defined.
There is little harm in always using -S and it fixes several issues:
- A race during 'make libraries' where, for example, libgcc_s is being
installed while another library is trying to link against it. This is
possible because libgcc_s is connected in both _prereq_libs and
_startup_libs. The first build (_prereq_libs) sets MK_PROFILE=no
while the 2nd pass (_startup_libs) enables MK_PROFILE. Thus the
libgcc_s library *is* present in WORLDTMP for other libraries to
link to, so serializing further items in _startup_libs is not
required. Just ensuring that libgcc_s is installed atomically (via
rename(2)) is enough. [1]
- Installation to a running system where some library that cannot be
detected, copied and used from the temporary INSTALLTMP with LD_LIBRARY_PATH
that the build itself uses for installation. Such an example is having the
install an NSS module for user lookups that install(1) uses while
concurrently installing the module in another process. This is not
a problem for the FreeBSD base build but can be for downstream
vendors. While this is a very specific case, installation to a
running system with non-atomic library installation is prone to many
problems. A further step still is to install in proper dependency
ordering.
Reported by: dhw many times [1]
Sponsored by: Dell EMC Isilon
MFC after: 2 weeks
== Rationale ==
r295380 introduced "make check" and consolidated means for running
test code in an attempt to simplify running tests. One could either
install files/libraries/programs and run "make check", or run "make check"
with an explicit CHECKDIR, e.g., `make check CHECKDIR=$(make -V.OBJDIR)``.
One criticism that was received is that "make check" should be run with
the intent of making dev->test->commit easier, which means that the target
audience's workflow should be developers. One developer pattern available
in other opensource projects is to run test code from a developer sandbox,
instead of installing to a system.
== Method ==
This approach is slightly different from the standard approach, in the sense
that it builds and installs into a deterministic directory under .OBJDIR (as I call it,
the "sandbox"), then runs "make check" against that. In the event the test
run is successful, the deterministic directory is removed to save space.
== Approach ==
bsd.lib.mk, bsd.prog.mk:
To support this functionality, a new variable `HAS_TESTS` is being added.
HAS_TESTS enables appropriate behavior with bsd.lib.mk and bsd.prog.mk, as
follows:
- Add "make check" as an available target from the directory.
- Pass down appropriate variables via ${TESTS_ENV}, i.e.,
${TESTS_LD_LIBRARY_PATH} and ${TESTS_PATH}.
One should add "HAS_TESTS" to directories containing tests in them, e.g. from
bin/sh/Makefile,
HAS_TESTS=
SUBDIR.${MK_TESTS}+= tests
HAS_TESTS doesn't automatically add the tests subdirectory for flexibility
reasons.
bsd.opts.mk, src.opts.mk:
- The knob ${MK_MAKE_CHECK_USE_SANDBOX} has been added, both to explicitly
direct (internally) when to set a deterministic ${DESTDIR} and to also allow
users to disable this behavior globally, i.e., via src.conf.
- MK_TESTS has been promoted from src.opts.mk to bsd.opts.mk to leverage
syntactic sugar for having MK_TESTS be a dependency for
MK_MAKE_CHECK_USE_SANDBOX, but to also ensure that src.opts.mk isn't required
to use suite.test.mk (which is a dependency of bsd.test.mk).
suite.test.mk:
- beforecheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified
from a no-op to:
-- Build.
-- Run "make hierarchy" on the sandbox dir.
-- Install the tests/files to the sandbox dir.
- aftercheck behavior (when MK_MAKE_CHECK_USE_SANDBOX is enabled) is modified
from a no-op to:
-- Remove the sandbox dir.
Again, because the dependency order set in bsd.test.mk is
beforecheck -> check -> aftercheck, "make check" will not be run unless
"beforecheck" completes successfully, and "aftercheck" will not be run unless
"beforecheck" and "check" complete successfully.
== Caveats ==
- This target must either be run with MK_INSTALL_AS_USER or as root. Otherwise
it will fail when running "make install" as the default user/group for many
makefiles when calling INSTALL is root/wheel.
- This target must be run from a suitable top-level directory. For example,
running tests from `tests/sys/fs/tmpfs` won't work, but `tests/sys/fs` will,
because `tests/sys/fs/tmpfs` relies on files installed by `tests/sys/fs`.
- Running MK_INSTALL_AS_USER may introduce determinism issues. However, using
it could identify deficiences in tests in terms of needing to be run as
root, which are not properly articulated in the test requirements.
- The doesn't negate the need for running "make installworld" and
"make checkworld", etc. Again, this just is intended to simplify the
dev->test->commit workflow.
== Cleanup done ==
- CHECKDIR is removed; one can use "MK_MAKE_CHECK_USE_SANDBOX=no" to enable
"legacy" (r295380) behavior.
MFC after: 2 months
Relnotes: yes (CHECKDIR removed; "make check" behavior changed)
Requested by: jhb
Reviewed by: arch (silence), testing (silence)
Differential Revision: D11905
Running `make libfoo.ll` or `make libfoo.bc` within a library directory
will now give us an LLVM IR version of the library, and `make foo.full.ll`
or `make foo.full.bc` will give us an IR version of a binary.
As part of this change, we add an LLVM_LINK variable to sys.mk that can be
specified/overridden using an external toolchain.
Reviewed by: bdrewery, brooks
Approved by: rwatson (mentor)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8388
Refactor make suffix rules into separate files (one for POSIX and one not),
and rationalise the rules so that bsd.lib.mk can contain only those rules
that are library-specific (.c.po and .c.pico).
This can be accomplished by adding ${STATIC_CFLAGS} to the .c.o rule
unconditionally. STATIC_CFLAGS are only defined for use by sys.mk rules in
lib/libpam/Makefile.inc (see r227797), so it should be safe to include
them unconditionally in sys.mk's .c.o rule (tested by make universe and a
ports exp-run).
Reviewed by: bdrewery, sjg
Approved by: rwatson (mentor)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D6805
build can break when different source files create the same target
files (case-insensitivity speaking). This is the case for object
files compiled with -fpic and shared libraries. The former uses
an extension of ".So", and the latter an extension ".so". Rename
shared object files from *.So to *.pico to match what NetBSD does.
See also r305855
MFC after: 1 month
Sponsored by: Bracket Computing
Differential Revision: https://reviews.freebsd.org/D7906
This is important to allow a Makefile to override OBJS_DEPEND_GUESS for
handling in META_MODE when its depend files are missing.
Approved by: re (implicit)
Sponsored by: EMC / Isilon Storage Division
A simplified example of the library targets with WITH_DEBUG_FILES is:
libgeom.so.5: libgeom.so.5.full
cp libgeom.so.5.full libgeom.so.5
libgeom.so.5.full:
ln -s libgeom.so.5 libgeom.so
cc -o libgeom.so.5.full *.o
Before, or without, WITH_DEBUG_FILES it is:
libgeom.so.5:
ln -s libgeom.so.5 libgeom.so
cc -o libgeom.so.5 *.o
The problem is that bmake considers the link source for the libgeom.so
link in the libgeom.so.5.full target as being a dependency for
libgeom.so.5.full. That resolves to libgeom.so.5. Thus a cyclic
dependency is created. The result of this is that if libgeom.so.5 is
created with a newer timestamp than libgeom.so.5.full, then
libgeom.so.5.full will be rebuilt on the next build. This causes a
chain reaction of everything in the build relinking, or hitting the
problem itself.
Moving the link creation to the target that actually creates
libgeom.so.5 fixes the problem. The simplest fix here is to just
duplicate the logic.
Submitted by: sjg
Approved by: re (implicit)
This breaks cross-building with WITH_META_MODE since it will rebuild
'build-tools' during the 'everything' phase.
A more proper fix is coming to bmake to implicitly require .META unless
.NOMETA (and other restrictions) are in place.
Adding .META to targets-to-build will ensure that they will rebuild if there
is no .meta file.
Adding it to all SUFFIXES and objects ensures that at least objects will
rebuild if there is no .meta file.
This will be reverted if bmake's behavior changes to rebuild on missing .meta
files.
Sponsored by: EMC / Isilon Storage Division
We want to avoid .text relocations in shared objects. libcrypto was the
only consumer and it is now fixed (as of r299389). Remove the now-unused
support for turning off the linker warning.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D6323
This overrides the cross-compiler's default sysroot to use the WORLD32's
sysroot for building the lib32 libraries. Previously the cross-compiler
would default the sysroot to the 64bit WORLDTMP and -B/-L/-isystem flags
were used to build using the lib32 files. This leads to multiple issues
discussed later. Some extra headers are now needed to be staged since the
64bit WORLDTMP is not referenced at all for headers. The 64bit WORLDTMP
is still used via PATH for build tools. Overriding the default
target/arch is retained in the CC/CXX overrides.
This allows reverting the LDSCRIPT rewriting in installworld from r296921 and
r235122, thus allowing read-only objdirs to work for installing again.
This removes the need for _LDSCRIPTROOT.
This allows progressing the change to always use --sysroot for the build
rather than only relying on the cross-compiler's default sysroot. The
work for that is in D3970 and needed to resolve WITHOUT_CROSS_COMPILER
not using a --sysroot [1].
PR: 196193 [1]
Sponsored by: EMC / Isilon Storage Division
Specifically this fixes /usr/lib/libc.so stripping the paths to the
libraries. The reason for this in r266227 was both likely because ld(1) did
not fully respect --sysroot until r291226 and because of the lib32
build. The lib32 build does not use --sysroot into the /usr/lib32 path,
rather it only uses -L and -B into the /usr/lib32 path and --sysroot
into the normal (64bit) /usr/lib. The _LDSCRIPTROOT was added with
the ldscript support in bsd.lib.mk so that it builds a 32-bit-sysrooted pathed
ldscript in the object directory and then installs a normal unprefixed
version in installworld. This commit also fixes the rebuild during
install which was broken in r266227. This commit would break DIRDEPS_BUILD
build of lib32 but it does not currently have a way to build it anyhow.
For example, before this change we had in /usr/lib/libc.so:
GROUP ( libc.so.7 libc_nonshared.a libssp_nonshared.a )
Now it is restored to pre-r266227:
GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a /usr/lib/libssp_nonshared.a )
The motivation for this is in testing of lld.
From emaste:
lld does not have built-in search paths (e.g. /lib, /usr/lib) and relies on
-L arguments passed by the caller. As the linker is nearly always invoked
from the clang driver this is fine other than the fact that /usr/lib/libc.so
is an ldscript that refers to libc.so.7 which is in /lib, not /usr/lib.
PR: 207980
Reported by: emaste
Submitted by: emaste (based on)
Differential Revision: https://reviews.freebsd.org/D5637
Currently the base.txz distribution does not get the BSD.debug.dist mtree
extracted into it. So if you start from that and then try to build a 3rd-party
application outside of buildworld it will by-default try installing the
debug files into a missing directory if they are being installed into /usr/lib.
Check for the existence before forcing the directory to be created rather than
the older way of running a shell command with test -d || mkdir -p always.
Reported by: HardenedBSD (https://github.com/HardenedBSD/secadm/issues/23)
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D5411
