lang/python26 -- without threads
The port lang/python26 can be built with or without threads. If built without the package will not install the file: %%PYTHON_LIBDIR%%/lib-dynload/_multiprocessing.so This causes error building a package from the port as well as maintaining it afterwards. I don't know the exact magic-foo to fix this kind of problem in the ports collection but I can look it up and find it. I'm just under the gun on another project right now. When I can revisit this I'll come up with a solution for the problem, put in a proper PR and a patch to fix the Makefile and or pkg-plist. -- Chris There will be an answer, Let it be. ch...@vindaloo.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: port: security/cfs
On Sep 17, 2008, at 7:52 PM, Edwin Groothuis wrote: On Wed, Sep 17, 2008 at 06:38:56PM -0400, Christopher Sean Hilton wrote: The port security/cfs, Matt Blaze's userland Cryptographic filesystem, is marked as broken because it does not compile under FreeBSD-7.0 or later. ports/127457 Thanks for the patch once I recognized that it was against existing patches in the ports files directory it went smoothly. -- Chris -- Chris Hilton chris-at-vindaloo-dot-com All I was doing was trying to get home from work! -- Rosa Parks ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
port: security/cfs
The port security/cfs, Matt Blaze's userland Cryptographic filesystem,
is marked as broken because it does not compile under FreeBSD-7.0 or
later.
I've managed to get it to compile through some simple changes but I
don't know enough about RPC to know if I am on the right track. I'm
asking for the help of an RPC wizard to check my train of thought.
The big change is rpcgen. In FreeBSD 6.0 it builds a C header file
with prototypes like this:
void * rpc_entry_point();
Now it builds prototypes like this:
void * rpc_entry_point(struct yourtype * yourvar, CLIENT * clnt);
I'm guessing that the first prototype caused GCC 4.x to gag so rpcgen
was patched to produce the second when the move was made to FreeBSD-7.0.
The second problem is that CFS is coded with rpc entry points that
look like this.
void * rpc_entry_point(yourvar, rp)
struct yourtype * yourvar;
struct svc_req *rp;
{
int ret = 0;
...
return ret;
}
While gcc doesn't completely gag on that one it's not that happy about
it either.
The small issue here is that the coding style is ancient. Returning an
(int) 0 as NULL has been taboo in C for years and gcc is getting more
and more fussy about these problems as time passes. The bigger problem
is that the parameter types don't match up. But the mismatch is so
huge that I find it difficult to believe that code ever worked.
Looking further into things I discovered that rpcgen is basically
specifying an client-server interface. For every:
void * rpc_entry_point(struct yourtype * yt, CLIENT * clnt);
You also get:
void * rpc_entry_point_svc(struct yourtype *yt, struct svc_req
*rp);
Now CFS uses KR to mangle up the _svc functions pretty well to but
basically if you patch cfs_adm.c and cfs_nfs.c to change the rpc entry
points from client to service definitions then the code compiles
reasonably cleanly with gcc 4.
After that long discussion does someone know RPC programming well
enough to verify that CFS was defining the Service side of thing all
along and that in the past RPC was loose enough to take
rpc_entry_point(... as the definition of the service which is now
properly called rpc_entry_point_svc(... ?
-- Chris
--
Chris Hilton chris-at-vindaloo-dot-com
All I was doing was trying to get home from work!
-- Rosa Parks
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
