NetBSD

History

he 6cf367a4a1 Fix up Heimdal so that it can be built statically, allowing the sun2 port to proceed beyond trying and failing to build Heimdal. This is done by: 1) Stop pretending that libipc is a separate library, and instead build it as part of libkrb5. The version map for libkrb5 needed to be updated to expose the required symbols from libipc. 2) The lexer in libhx509 needs to use its own prefix, so that the resulting library can be statically linked with a lexer which uses the default prefix. This was hidden because libhx509's version map file (which is only used for the shared libs) hid away the lexer symbols. Some defines needed tweaking as well to restore buildability. 3) Excplicitly mention all the required libraries in LDADD+= and make sure DPADD is set to correspond. This allows static linking; earlier this relied on shared library dependencies to have all the libs pulled in. In the process, convert to single-line LDADD+= and DPADD+= settings. Use Makefile.inc for the common libraries to the extent possible. Successfully built from scratch for i386 and sun2 several times, and for lots of other ports as well. Discussed with elric@ and christos@.	2011-05-25 19:21:16 +00:00
..
bsd	Fix up Heimdal so that it can be built statically, allowing the	2011-05-25 19:21:16 +00:00
README	update paths	2009-01-22 00:01:52 +00:00

he 6cf367a4a1 Fix up Heimdal so that it can be built statically, allowing the

sun2 port to proceed beyond trying and failing to build Heimdal.
This is done by:

1) Stop pretending that libipc is a separate library, and instead
   build it as part of libkrb5.  The version map for libkrb5 needed
   to be updated to expose the required symbols from libipc.

2) The lexer in libhx509 needs to use its own prefix, so that the
   resulting library can be statically linked with a lexer which
   uses the default prefix.  This was hidden because libhx509's
   version map file (which is only used for the shared libs) hid
   away the lexer symbols.  Some defines needed tweaking as well
   to restore buildability.

3) Excplicitly mention all the required libraries in LDADD+= and
   make sure DPADD is set to correspond.  This allows static linking;
   earlier this relied on shared library dependencies to have all the
   libs pulled in.  In the process, convert to single-line LDADD+=
   and DPADD+= settings.  Use Makefile.inc for the common libraries
   to the extent possible.

Successfully built from scratch for i386 and sun2 several times,
and for lots of other ports as well.

Discussed with elric@ and christos@.

2011-05-25 19:21:16 +00:00

bsd

Fix up Heimdal so that it can be built statically, allowing the

2011-05-25 19:21:16 +00:00

README

update paths

2009-01-22 00:01:52 +00:00

README

$NetBSD: README,v 1.2 2009/01/22 00:01:52 lukem Exp $

Organization of Sources:

This directory hierarchy is using an organization that separates
crypto source for programs that we have obtained from external third
parties (where NetBSD is not the primary maintainer) from the system
source.

This README file is derived from the README file in src/external.

The hierarchy is grouped by license, and then package per license,
and is organized as follows:

	crypto/external/

	    Makefile
			Descend into the license sub-directories.

	    <license>/
			Per-license sub-directories.

		Makefile
			Descend into the package sub-directories.

		<package>/
			Per-package sub-directories.

		    Makefile
			Build the package.
			
		    dist/
			The third-party source for a given package.

		    bin/
		    lib/
		    sbin/
			BSD makefiles "reach over" from these into
			"../dist/".

This arrangement allows for packages to be easily disabled or
excised as necessary, either on a per-license or per-package basis.

The licenses currently used are:

	bsd		BSD (or equivalent) licensed software, possibly with
			the "advertising clause".

If a package has components covered by different licenses
(for example, GPL2 and the LGPL), use the <license> subdirectory
for the more restrictive license.

If a package allows the choice of a license to use, we'll
generally use the less restrictive license.

If in doubt about where a package should be located, please
contact <core@NetBSD.org> for advice.


Migration Strategy:


Eventually src/dist (and associated framework in other base source
directories) and src/gnu will be migrated to this hierarchy.


Maintenance Strategy:

The sources under src/crypto/external/<license>/<package>/dist/ are
generally a combination of a published distribution plus changes
that we submit to the maintainers and that are not yet published
by them.

Make sure all changes made to the external sources are submitted
to the appropriate maintainer, but only after coordinating with
the NetBSD maintainers.