On Fri, 1 Nov 2002, Jan Harkes stipulated:
> On Fri, Nov 01, 2002 at 12:03:47AM +, Nix wrote:
>> On Wed, 30 Oct 2002, Jan Harkes moaned:
>> > Similarily, allocation of persistent objects, it used to be the case
>> > that the range [&foo, &foo+sizeof(foo)] would contain all information
>> > asso
In [EMAIL PROTECTED], Jan Harkes <[EMAIL PROTECTED]>
wrote:
> I'm not sure whether I can really get away without any constructors or
> overloaded allocators. If we really have to lose those it is probably
> better to only access RVM objects through a well defined layer written
> in C.
OK, wack
On Fri, Nov 01, 2002 at 12:03:47AM +, Nix wrote:
> On Wed, 30 Oct 2002, Jan Harkes moaned:
> > Similarily, allocation of persistent objects, it used to be the case
> > that the range [&foo, &foo+sizeof(foo)] would contain all information
> > associated with a C++ object. However the newer gcc's
On Wed, 30 Oct 2002, Jan Harkes moaned:
> Similarily, allocation of persistent objects, it used to be the case
> that the range [&foo, &foo+sizeof(foo)] would contain all information
> associated with a C++ object. However the newer gcc's store miscelaneous
> data outside of that range, often even
> "Jan" == Jan Harkes <[EMAIL PROTECTED]> writes:
Jan> I am also suspicious whether gcc-3.x might be overly
Jan> agressive in reordering code as it seems like locks are
Jan> sometimes not properly taken/released in the right places.
This seems to have been observed up to GCC 3.1 a
On Wed, 30 Oct 2002 14:29:46 -0500
Jan Harkes <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 30, 2002 at 01:23:48PM -0500, Jan Harkes wrote:
> >
>
> I guess I might have been a bit overly negative. Most of my experience
> was when compiling with 3.0. In general gcc-3 actually compiles more
> correctly
On Wed, Oct 30, 2002 at 01:23:48PM -0500, Jan Harkes wrote:
>
I guess I might have been a bit overly negative. Most of my experience
was when compiling with 3.0. In general gcc-3 actually compiles more
correctly, which causes latent bugs that don't show up with older c++
compilers to surface.
Ja
On Wed, Oct 30, 2002 at 10:28:52AM +0100, Marcel Pol wrote:
> I started using codafs very recently, and I noticed it only builds with
> gcc-2.9x.
Correct.
> My question is if the next version of coda can be built with gcc-3.2. If not,
The problem is that gcc-3.x breaks a lot of assumpt
On Wed, 30 Oct 2002, Marcel Pol wrote:
> Ok thanks for the information.
> I'll be trying out a cvs version then, and see how it goes.
> I assume I only need to download coda from cvs, and not lwp, rpc2 and rvm,
> right?
I would recommend cvs rvm, too, as it fixes some potential errors.
Looks like
any guarantee of course,
> but I am running recent Coda (cvs, later than 5.3.19) and using gcc 3.2.
> So far I have no good reason to believe gcc-3.2 breaks the code, as when I
> wanted sometimes to exclude it as a reason for errors, I recompiled with
> 2.95.4 and got the same behavior p
Hello Marcel,
On Wed, 30 Oct 2002, Marcel Pol wrote:
> Hello,
> I started using codafs very recently, and I noticed it only builds with
> gcc-2.9x.
I cannot give you any guarantee of course,
but I am running recent Coda (cvs, later than 5.3.19) and using gcc 3.2.
So far I have no good
Hello,
I started using codafs very recently, and I noticed it only builds with
gcc-2.9x.
For Mandrake Linux, there is a codafs package in contribs, which is 5.3.17,
which I'd like to update to 5.3.19. The problem is that it has switched to the
gcc-3.2 compiler. For the latest release there
12 matches
Mail list logo
