on the setting of ${SHLIBDIR} and ${SHLIBINSTALLDIR} (_not_ ${_LIBSODIR}).
Fixes cruel and unusual ^W^W^W obscure native-build and not-so-obscure
cross-builds problems I was having with shared libraries with a
non-base LIBDIR (e.g, /usr/X11R6/lib) that use LDADD to pull in other
libraries from /usr/lib (such as libm) which are really in /lib and the
symlink from ${DESTDIR}/usr/lib/libm.so to /lib/libm.so.N.M was confusing
the linker. Stuffing -rpath-link ${DESTDIR}/lib in solves the problem.
This should mean that shared libraries that depend upon other shared
libraries in other directories should DTRT in a DESTDIR (cross-)build...
Inspired by _PROGLDOPTS in <bsd.prog.mk>
can set CHECKFLIST_FLAGS="-e" in mk.conf so that extra files in
$DESTDIR are `non fatal'.
Remove unused '${CHECKFLISTFLAGS}' (which allowed selection of
different checkflist target in maketars target)
interface controllers (of varying intelligence levels).
Contributed by Wasabi Systems, Inc. Primarily written by Steve Woodford,
with some modification by me.
throughput significantly in a wide variety of test cases, including
local gigabit ethernet with both jumbo and standard frames,
transcontinental (U.S.) connections with e2e bandwidths ranging from
10Mbit/sec to 155Mbit/sec, and on a variety of test connections
between the NetBSD Project public servers and machines in Australia.
The impact of this change is less dramatic for high-delay connections
when Path MTU is in use but still measurable.
For optimal performance on local gigabit networks, a higher socket
buffer size (at least 64K) will still yield a substantial improvement
in performance, but 32K gets us most of the way there in my test
cases, with only a cost of _doubling_ memory use per socket rather
than _quadrupling_ it.
N.B. Windows NT, at least since Win2k SP2, uses a default socket buffer
size (or their analogue thereof) of 64K, which is a useful data
point.
This fixes a bug introduced in revision 1.120 of ffs_vfsops dated 2003/09/13
which results in fs_flags having a value of 0x7fffff00 when a superblock
is updated to use the new layout.
Discussed in http://mail-index.netbsd.org/tech-kern/2003/09/28/0003.html
