| Age | Commit message (Collapse) | Author |
|---|
|
|
|
bsd.port.mk is included; define CONFIGURE_SHARED that is set to
either --enable-shared or --disable-shared depending upon the
architecture.
|
|
when they're invoked with an absolute path.
This was introduced by the WRKBUILD/WRKSRC split.
So:
- replace default CONFIGURE with a full path, so that you can override it.
- remove leading ${WRKSRC} from the configure invocation.
- add . to the configure path.
|
|
move sections around to match mdoc.template
|
|
|
|
peers by ORing the two together and NAKing or REQing
the result rather than allowing seperate local/peer
values.
If the peer REJs our ACCMAP and our ACCMAP isn't 0,
warn about it and ignore the rejection.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
up [options]
Any of the following may or may not be set:
$name $mask $bcaddr $extras
|
|
|
|
|
|
|
|
|
|
|
|
o new ioctls for getting/setting cache size (default == 100)
o changed SIOCBRDGRT -> SIOCBRDGRTS
o changed SIOCBRDGIDX -> SIOCBRDGIFS
|
|
|
|
|
|
mostly harmless otherwise).
|
|
|
|
|
|
``closing''.
Pointed out by: archie
Don't do a TLF when we get a ``Catastrphic Protocol Reject'' event
in state ``closed'' or ``stopped''.
Pointed out but not suggested by: archie
This makes no difference in the current implementation as
LcpLayerFinish() does nothing but log the event, but I disagree
in principle because it unbalances the TLF/TLS calls which
(IMHO) doesn't fit with the intentions of the RFC.
Maybe the RFC author had a reason for this. It can only happen
in two circumstances:
- if LCP has already been negotiated then stopped or closed and we
receive a protocol reject, then we must already have done a TLF.
Why do one again and stay in the same state ?
- if LCP hasn't yet been started and we receive an unsolicted
protocol reject, why should we TLF when we haven't done a TLS ?
|
|
|
|
Make 'disklabel -ed' not overwrite your label if you make no changes
in the editor (added a cmplabel function to compare two labels).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
we're already in network phase and our autoload values
are set with no minimum threshold (the default).
Tell the autoload timer that it's ``coming up'' *before*
calling AutoLoadTimeout() directly... not after. This
prevents the very first demand-dial connection from
immediately disconnecting when there are other auto links.
Problem diagnosis: Ted Mittelstaedt <tedm@toybox.placo.com>
|
|
cookies, so that cookie names are no longer hard-coded.
* new SEPARATE_BUILD feature: for ports that can build outside their source
tree, use build-${ARCH} to build, and move configure/build/install cookie
down inside build-${ARCH}.
Those few people who use NFS to mount ports tree around different
architectures may find this helps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Marc Espie writes:
> I haven't really been able to follow thru the code (and my current build
> is not finished yet, so I can't do the check myself), but your recent patch
>
> to handle weak correctly does look like __attribute__((weak)) will work
> correctly only if HANDLE_PRAGMA_WEAK is asserted.
>
> This is a problem, as HANDLE_PRAGMA_WEAK is a choice, not a feature (at
> least, that's what the gcc.info documentation seems to imply for
> HANDLE_SYSV_PRAGMA).
When HANDLE_PRAGMA_WEAK is false, the code will continue to fail as it has
failed for years. Not perfect by any means. Feel free to fix it. It is
still a choice, selecting that choice is the only way to get functional
weak support right now.
What needs to happen long term is the generic weak/alias code needs to become
unconditional and only the pragma parsing of that code be conditional.
|
