support shared libraries (sun2 and evbsh5 at it would seem), or if the
user has specified MKPIC=no. Also introduce a new tag to the set lists
("pam"), so that the non-shlib ports can once again complete a release
build.
Discussed with christos and lukem.
libraries to LDADD & DPADD for the current library, using -L OBJDIR-of-DEPLIB
so that the current library can link with the DEPLIB library built but
not installed.
Set DEPLIBS appropriately, rather than explictly adding LDADD/DPADD
for various libraries.
Reorder library build order so that libraries that depend upon any
other library are built at the end.
Whilst this change could be done in a more generic manner (and I
intend to work on that), it does remove the need to implement
top-level build targets such as "do-lib-des" (etc).
and without Kerberos 4 & 5 (MKKERBEROS=no). Previously checkflist
complained of missing files.
* move kerberos- and kerberos 4-only files into new flists,
distrib/sets/lists/*/krb.*
* make the flist generators grok MKKERBEROS{,4} variables
* fix Makefiles which treat MKKERBEROS=no as MKKERBEROS5=no.
9 out of 10 experts agree that it is ludicrous to build w/
KERBEROS4 and w/o KERBEROS5.
* fix header files, also, which treat MKKERBEROS=no as MKKERBEROS5=no.
* omit some Kerberos-only subdirectories from the build as
MKKERBEROS{,4} indicate
(I acknowledge the sentiment that flists are the wrong way to go,
and that the makefiles should produce the metalog directly. That
sounds to me like the right way to go, but I am not prepared to do
revamp all the makefiles. While my approach is expedient, it fits
painlessly within the current build architecture until we are
delivered from flist purgatory, and it does not postpone our
delivery. Fair enough?)
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.
MKSHARE=no turns off MKNLS (sets it into "no") and /usr/src/Makefile builds
src/lib with MKSHARE=no.
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
don't use unsigned long where 32bit unsigned variable is asked for.
use u_int32_t. (not sure if uint32_t is better or not, but anyway,
u_int32_t <-> uint32_t should not raise binary compatibility issue)
PR10921.
TODO: have arch-dependent Makefiles where we supply -DFOO for optimization.
(do not change size of variable though)
XXX: we should actually nuke all other #ifdef in /usr/include/openssl/*.h,
however, that needs a lot of work and will make future openssl upgrade harder.
remove RC5 and IDEA by default. build them separately as
libcrypto_{rc5,idea}.a. put dummy function, which is "warning to stderr
and exit(1)". NOCRYPTO_{RC5,IDEA} are obsoleted.
PR10883.
adding support for Heimdal/KTH Kerberos where easy to do so. Eliminate
bsd.crypto.mk.
There is still a bunch more work to do, but crypto is now more-or-less
fully merged into the base NetBSD distribution.
christos