myself (for the lack of children, whom I could've prohibited to
do it). Sorry.
Upgrade this port to:
. build against TCL-8.3 by default (controllable by TCL_VER)
. build with or without TK (controllable by NO_X)
. take over maintainership -- regretfully, Justin was
rather idle recently
. build the helpfiles once -- during the build stage --
not during the install stage
On a side note, I more and more resent the fact, that our TCL
8.3 is built with the -stubs. It just introduces more variables
without noticeable benefit. On FreeBSD shared libraries work
well...
I tested this with TCL-8.3 (with and without TK), and with
TCL-8.2 (without TK only). Please, test this more.
by forcing the CFLAGS to -O -pipe. Somehow, the alpha build always
tries to enforce a particular -mcpu=ev4 flag which of course cannot be
understood by the (AVR) xgcc later on. This looks to me like a bug in
the cross-compilation environment of gcc, but i'm tired of actually
finding the bug.
The compiled result of avr-gcc MD5 compares equal to something build
from an IA32 host platform.
shell. Pipes and redirections work just as expected:
sh = Shell.cd("/foo")
sh.cat("bar") | sh.tee("baz") > "baa"
# or
sh.transact do
cat("bar") | tee("baz") > "baa"
end
next version. In the meantime, apply with the port.
FYI, the bug is demonstrated by this program:
#include <stdio.h>
#include <stdlib.h>
#include <pth.h>
static int check_something(void *arg)
{
return (0);
}
static void *thread(void *arg)
{
printf("thread sleeping five seconds...\n");
pth_nap(pth_time(5, 0));
printf("thread is done sleeping\n"); /* bug: we never get here */
return (NULL);
}
int main(int ac, char **av)
{
pth_event_t ev;
pth_init();
pth_spawn(NULL, thread, NULL);
ev = pth_event(PTH_EVENT_FUNC, check_something, NULL, pth_time(2, 0));
while (1)
pth_wait(ev);
}
Specefic remote commands will cause the daemon process starts to consume
all CPU and memory resources available to it. Multiple simultaneous
instances will result in faster depletion of resources, causing either
the daemon process or the server to crash.
(http://bugs.proftpd.org/show_bug.cgi?id=1066)
This would cure headache like apache module linking against libpq
fail to work after rebooting.
Originally, maintainer and I want this commit to go with the
PostgreSQL updating. But we both think that the latest PostgreSQL
would not be released before FreeBSD 4.3-RELEASE ports freeze.
As a conclusion, PORTREVISION bumped.
Discussed with/Submitted by: MAINTAINER
