have three variables:
EXEC_DEPENDS - A list of "prog:dir" pairs of other ports this
package depends on. "prog" is the name of an
executable. make will search your $PATH for it and go
into "dir" to do a "make all install" if it's not found.
LIB_DEPENDS - A list of "lib:dir" pairs of other ports this package
depends on. "lib" is the name of a shared library.
make will use "ldconfig -r" to search for the
library. Note that lib can be any regular expression,
and you need two backslashes in front of dots (.) to
supress its special meaning (e.g., use
"foo\\.2\\.:${PORTSDIR}/utils/foo" to match "libfoo.2.*").
DEPENDS - A list of other ports this package depends on being
made first. Use this for things that don't fall into
the above two categories.
DEPENDS behaves exactly like before, so old Makefiles will still work
the same. The two variables are lists of pairs as described above.
For instance, if your program depends on unzip and libjpeg.5.*, use
the following definitions:
EXEC_DEPENDS= unzip:${PORTSDIR}/archivers/unzip
LIB_DEPENDS= jpeg\\.5\\.:${PORTSDIR}/graphics/jpeg
gmake:${PORTSDIR}/utils/gmake is automatically added to EXEC_DEPENDS
if USE_GMAKE is defined.
If NO_DEPENDS is defined, the list will just be printed out one by one.
Add a missing apostrophe that suggests inverting the frequency to get
tick size. It read better before because `CLK_TCK' suggests a tick
size although it is actually a frequency.
Define CLK_TCK only if _ANSI_SOURCE is not defined.
Don't include <machine/limits.h> to get the definition of CLK_TCK.
CLK_TCK should never have been defined there, and the inclusion
polluted the namespace.
message instead of relying on the fact that we are scheduled to send them.
The old method worked 99.9% of the time, but someone reported some periferals
that did MSG_REJECT at odd times (sometimes before we could send an SDTR
or WDTR) that we would construe as the response to an SDTR or WDTR message.
This also removes a possible race condition where after a bus reset (the
result of a command time out not during intial probe time), we might queue
two commands both requesting SDTR, WDTR or both.
i reported today earlier..tested and works OK..
( To those who want to experience bug try running aub
with old version of socket.ph and with new one or just any
perl script "requiring " <sys/socket.ph> or <sys/cdefs.ph> )
in serious system instability. Changed a B_INVAL to a B_NOCACHE so that
buffer data is properly disposed of.
Submitted by: John Dyson, Rick Macklin, and ohki@gssm.otsuka.tsukuba.ac.jp
as an NIS client. The pw_breakout_yp routines that are used to populate the
_pw_passwd structire only do anything if the bits in the pw_fields member
_pw_passwd are cleared. Unfortunately, we can get into a state where
pw_fields has garbage in it right before the YP lookup functions are
called, which causes the breakout functions to screw up in a big way.
Here's how to duplicate the problem:
- Configure FreeBSD as an NIS client
- Log in as a user who's password database records reside only in
the NIS passwd maps.
- Type ps -aux
Result: your processes appear to be owned by 'root' or 'deamon.'
/bin/ls can exhibit the same problem.
The reason this happens:
- When ps(1) needs to match a username to a UID, it calls getpwuid().
- root is in the local password file, so getpwuid() calls __hashpw()
and __hashpw() populates the _pw_passwd struct, including the pw_fields
member. This happens before NIS lookups take place because, by coincidence,
ps(1) tends to display processes owned by root before it happens upon
a proccess owned by you.
- When your UID comes up, __hashpw() fails to find your entry in the
local password database, so it bails out, BUT THE BITS IN THE pw_fields
STRUCTURE OF _pw_passwd ARE NEVER CLEARED AND STILL CONTAIN INFORMATION
FROM THE PREVIOUS CALL TO __hash_pw()!!
- If we have NIS enabled, the NIS lookup functions are called.
- The pw_breakout_yp routines see that the pw_fields bits are set and
decline to place the data retrieved from the NIS passwd maps into the
_pw_passwd structure.
- getpwuid() returns the results of the last __hashpw() lookup instead
of the valid NIS data.
- Hijinxs ensue when user_from_uid() caches this bogus information and
starts handing out the wrong usernames.
AAAARRRRRRRRRGGGGGGHHHHHHHHHH!!!
*Please* don't tell me I'm the only person to have noticed this.
Fixed by having __hashpw() check the state of pw_fields just before
bailing out on a failed lookup and clearing away any leftover garbage.
What a fun way to spend an afternoon.
definitions taken from the PCI specs. Part of them were typed
in by Wolfgang Stanglmeier, the (at that time unneeded) rest
by Charles Hannum (thanks !).
may be the result of reselect following too fast for
the driver to notice. Not the final solution, but the
problem has been seen only with very few devices.
Reviewed by: se
Submitted by: wolf (Wolfgang Stanglmeier)
