Date: Tue, 21 Oct 2003 00:41:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: jcw@highperformance.net Cc: freebsd-chat@freebsd.org Subject: Re: ACAP Server for FreeBSD Message-ID: <3F94E33C.89ED15BC@mindspring.com> References: <7915593.1066677341@[192.168.1.13]>
next in thread | previous in thread | raw e-mail | index | archive | help
jcw@highperformance.net wrote: > A quick search of "ACAP" in the ports tree yields nothing. Google show > some talk about CMU ACAP and UW ACAP circa 1998. Does anyone here run ACAP > to go with their IMAP servers? > > (Oh yeah, on FreeBSD hosts of course.) Jeremy Allison (of SAMBA) and I ported the CMU ACAP to FreeBSD around 1998. We didn't end up using it for anything (as far as I can tell, it's only real use at this point is configuring the Eudora Pro email clients). We did the port because we were going to use it to send various configuration options down to InterJets. I'm pretty sure that we were the first people to ever get it to actually compile at all, let alone run, using GNU tools, which were pretty poor at esoteric C++ back then. At the time, we were GCC 2.93 (I believe), and we had to fix the compiler to support per-thread exception stacks. We also had to patch FreeBSD to the point that it was fully compliant with the pthreads Draft 4 specification (the standard was Draft 10, and no one had fully implemented it yet). The per-thread exception stack code was not the exception stack code that the EGCS folks ended up using (our didn't have overhead except for threaded apps; the EGCS code always has overhead). In addition, there were a number of patches required for the STL from the Moscow Center for Supercomputing (the best STL at that time, and, I think, still). Specifically, the lack of a mutex initializer (PTHREAD_MUTEX_INITIALIZER) for statically declared mutexes was a problem because of the Draft 4 state of FreeBSD pthreads. This is unlikely to be a problem for you. In addition, we had to reorder the objects when we linked, since the static constructures were called in declaration order, and the code made no provision for construction of pur virtual base classes in the correct order on the compiler, so if you linked out of order, it was a problem (we found this out by comparing to the Sun SPARC compiler). This may or may not still be an issue. Finally, the GCC compiler puked on some of the explicit scoping of namespaces for constructors and things. This was fixable by simply adding a " "after the "::". I don't know if this is still an issue, but if it is, that's the fix. If you want to retry a port, it should basically "just configure and build" from the CMU tarball, and if it doesn't, your problems are likely to be one of those above. If you run into porting issues, you can give me a yell, and I'll probably answer. 8-). -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F94E33C.89ED15BC>