On Fri, Mar 07, 2003 at 03:04:51PM +1100, Tim Robbins wrote:
> venus from Coda 5.3.19 doesn't work on FreeBSD 5.0-current because free()
> detects heap corruption and aborts the program, and rdsinit (run from
> vice-setup-rvm) fails because librvm seems to depend on malloc()'d
> memory being zeroed. These bugs seem to be fixed in the latest release,
> but it still doesn't compile out of the box on FreeBSD 5. Part of this is
> due to gcc 3.2 being more picky about C++ code than 2.95.x.

5.3.19 was released March 12th 2002, which is almost a year ago. 5.3.20
was released December 13th 2002, almost three months ago. I can't really
help it that the ports tree didn't get updated.

gcc-3.2 is also causing compilation problems on recent Linux
distributions such as Mandrake, RedHat 8.0, SuSe and Debian unstable.
The current code in CVS has most of those problems fixed.

There are still a lot of warnings about 'invalid offsetof from non-POD
type' but those are harmless. In fact, using the suggested
pointer-to-member solution creates broken code when a trivial class
object is a member of a struct, the resulting offset is off by 1 byte
and as a result we can't get the right container object. (class in class
and struct in class work fine).

I had hoped that someone could have found the reason of the freelist
corruption, that is possibly still there. Valgrind did find some
problems related to uninitialized memory accesses in RVM, those could
have been related. Valgrinding venus was fun, I had to get everything
(rvm/rpc2/venus) to run on pthreads, but our threading model doesn't
like concurrency, and I've developed this strong suspicion that the
LinuxThreads pthread mutexes are broken when they are heavily used.

> By "support FreeBSD" I mean that it should compile and work without
> any local patches on the current releases (4.7 and 5.0).

Yeah, that would be nice ;)

Jan