They implement a space efficent write-once database with fast access
path. Switch the services(5) database to use cdb. The size of the
database file decreases from 2.1MB disk space to 307KB. Access
performance is about the same if setservent(0) is used and about an
order of magnitude faster otherwise. services_mkdb defaults to the new
format, but can optionally create the old db(3) format as well for
statically linked legacy applications.
Now the .c file is removed from SRCS for both .S and .c in NO_SRSC.
The .c file is added to LSRCS for .S files in NO_SRCS.
(.S files in SRCS have the same treatment - but also get compiled.)
Allows vax build to be fixed.
Also the previous version failed to add to LSRCS correctly.
SRCS and add to LSRCS (for lint).
Change the 'string' Makefiles so that the arch/*/string/Makefile.inc
need only specify the .S files for that architecture and not the .c
files for all the files they don't override.
- Apply patch from J.T. Conklin to execute .init/.fini functions in order.
- Support DF_1_INITFIRST and mark libc with DF_1_INITFIRST. Shared libs
should be recording a dependency on libc, but it's too late to do that.
Ok christos@.
for misc support routines and put it there.
- Add a libc constructor. Use this to initialize threading and the
stack protector stuff. libpthread cannot be initialized safely using
its own constructor because libc and libpthread are deeply intertwined.
PR bin/37347
(what other systems keep in libssp, we already have in libc) into libc
to match what other systems with FORTIFY_SOURCE do. Goodbye, libssp
dependency in libraries and executables. Discussed with christos and
mrg; Christos will merge the headers to get us the rest of the way to a
FORTIFY_SOURCE implementation that works as others' code expects.
CPPPICFLAGS obly affect *.s sources only,
but we want -D_I18N_DYNAMIC flag for *.c source
(src/lib/libc/citrus_module.c and so on).
use CPICFLAGS instead.
this fix suggested by tsutsui-san in current-users@, thanks.
program/tool from "FOO" to "TOOL_FOO". The new variables are:
TOOL_ASN1_COMPILE TOOL_CAP_MKDB TOOL_CAT TOOL_CKSUM TOOL_COMPILE_ET
TOOL_CONFIG TOOL_CRUNCHGEN TOOL_CTAGS TOOL_DB TOOL_EQN TOOL_FGEN
TOOL_GENCAT TOOL_GROFF TOOL_HEXDUMP TOOL_INDXBIB TOOL_INSTALLBOOT
TOOL_INSTALL_INFO TOOL_M4 TOOL_MAKEFS TOOL_MAKEINFO TOOL_MAKEWHATIS
TOOL_MDSETIMAGE TOOL_MENUC TOOL_MKCSMAPPER TOOL_MKESDB
TOOL_MKLOCALE TOOL_MKMAGIC TOOL_MKTEMP TOOL_MSGC TOOL_MTREE
TOOL_PAX TOOL_PIC TOOL_PREPMKBOOTIMAGE TOOL_PWD_MKDB TOOL_REFER
TOOL_ROFF_ASCII TOOL_ROFF_DVI TOOL_ROFF_HTML TOOL_ROFF_PS
TOOL_ROFF_RAW TOOL_RPCGEN TOOL_SOELIM TOOL_SUNLABEL TOOL_TBL
TOOL_UUDECODE TOOL_VGRIND TOOL_ZIC
For each, provide default in <bsd.sys.mk> of the form:
TOOL_FOO?= foo
and for the ${USETOOLS}=="yes" case in <bsd.own.mk>, provide override:
TOOL_FOO= ${TOOLDIR}/bin/${_TOOL_PREFIX}foo
Document all of these in bsd.README.
This cleans up a chunk of potential (and actual) namespace collision
within our build infrastructure, as well as improves consistency in
the share/mk documentation and provision of appropriate defaults for
each of these variables.
infrastructure and using that infrastructure in programs.
* MKHESIOD, MKKERBEROS, MKSKEY, and MKYP control building
of the infratsructure (libraries, support programs, etc.)
* USE_HESIOD, USE_KERBEROS, USE_SKEY, and USE_YP control
building of support for using the corresponding API
in various libraries/programs that can use it.
As discussed on tech-toolchain.
- add libc/citrus directory.
this directory contains the common stuffs not only for locale
but also other facilities relating to i18n (e.g. iconv).
- To keep the binary compatibility for the ctype modules easily,
the interface between libc and the modules is simplified.
- For the future integrated extension, module pool is renamed
from "/usr/lib/runemodule" to "/usr/lib/i18n".
In the future, this directory will contain the modules for "iconv",
"collation", etc.
- some cosmetic changes.
- Bug fix for runetype.h; __attribute__((__packed__)) is placed at
the wrong position and it is invalid unintentionally.
But, the all members of the structures seem well-aligned. Thus,
this bug causes no problem, hopefully.
HEADS UP:
- /usr/lib/rumemodule is obsoleted. If you use the multibyte locales,
you need to install /usr/lib/i18n/* from sys/lib/i18n_module .
- The binary compatibility of /usr/share/locale/*/LC_CTYPE is probably kept.
Perhaps, the bug fix about __packed__ mentioned above breaks the
compatibility... Be careful especially on 64bit platforms.
- SHLIBDIR Location to install shared libraries if ${USE_SHLIBDIR}
is "yes". Defaults to "/usr/lib".
- USE_SHLIBDIR If "yes", install shared libraries in ${SHLIBDIR}
instead of ${LIBDIR}. Defaults to "no".
Sets ${_LIBSODIR} to the appropriate value.
This may be set by individual Makefiles as well.
- SHLINKDIR Location of shared linker. Defaults to "/usr/libexec".
If != "/usr/libexec", change the dynamic-linker
encoded in shared programs
* Set USE_SHLIBDIR for libraries used by /bin and /sbin:
libc libcrypt libcrypto libedit libipsec libkvm libm libmi387
libtermcap libutil libz
* If ${_LIBSODIR} != ${LIBDIR}, add symlinks from ${LIBDIR}/${LIB}.so*
to ${_LIBSODIR}/${LIB}.so* for compatibility.
* Always install /sbin/init statically (for now)
The net effect of these changes depends on how the variables are set:
1.) If nothing is set or changed, there is no change from the
current behaviour:
- Static /bin, /sbin, and bits of /usr/*
- Dynamic rest
- Shared linker is /usr/libexec/ld*so
2.) If the following make variables are set:
LDSTATIC=
SHLINKDIR=/lib
SHLIBDIR=/lib
Then the behaviour becomes:
- Dynamic tools
- .so libraries used by /bin and /sbin are installed to /lib,
with symlinks from /usr/lib/lib*so to -> /lib/lib*so
where appropriate
- Shared linker is /lib/ld*so
3.) As per 2.), but add the following variable:
USE_SHLIBDIR=yes
This forces all .so's to be instaleld in /lib (with compat
symlinks), not just those tagged by their Makefiles to be.
Again, compat symlinks are installed
the functionality will be available for dynamic-linked binary only, due to
limitation with dlopen() from within statically-linked binaries.
(statically-linked binary can still enjoy singlebyte LC_CTYPE locale support)
from citrus project.
The code is (almost) a direct copy of the current arm26 sources.
It's identical to the current arm32 sources, with the following exceptions:
- _C_LABEL is used on references to C labels from assembler.
- Function returns in assembler have APCS-26 versions in #ifdef __APCS_26__.
- It uses SoftFloat 2a rather than SoftFloat 1a.
The first two of these should be inconsequential. I believe that SoftFloat 2a
should work on arm32 and be backward-compatible with existing code, but this
is not obviously true. For now, arm32 remains using its own bits of libc.
joerg