jean-frederic clere wrote:
Jim Jagielski wrote:
Except that, at least to me, it looks like apr_atomic_sparc.s itself
isn't totally portable among all Sparcs. Isn't 'cas' an 8+ opcode?
It is a 8+ opcode. It will not work on "old machines".
have a look at the configure for sparc for what machines t
Jim Jagielski wrote:
Except that, at least to me, it looks like apr_atomic_sparc.s itself
isn't totally portable among all Sparcs. Isn't 'cas' an 8+ opcode?
It is a 8+ opcode. It will not work on "old machines".
So to use apr_atomic_sparc.s, at a minimum we need that.
[dang, I really meant to reply to [EMAIL PROTECTED] the first time]
> +1 to either option. Enabled by default is probably okay since it will
> help us track down problems, so I'll lean toward --disable-atomic.
Although I'd really like to see the atomics code work, having to
specify --please-make
On 26 Apr 2002, Jeff Trawick wrote:
> I could go for that or for a --disable-atomic switch which could be
> used to alleviate any problems if they happen.
+1 to either option. Enabled by default is probably okay since it will
help us track down problems, so I'll lean toward --disable-atomic.
--
Jim Jagielski <[EMAIL PROTECTED]> writes:
> Maybe we should have atomics disabled by default, at least right
> now... with the build problems on some Linuxes and the Solaris
> compatibility stuff, it's been snagging us. I don't want it to
> delay 2.0.36 if possible.
I could go for that or for a -
Maybe we should have atomics disabled by default, at least right
now... with the build problems on some Linuxes and the Solaris
compatibility stuff, it's been snagging us. I don't want it to
delay 2.0.36 if possible.
--
===
Except that, at least to me, it looks like apr_atomic_sparc.s itself
isn't totally portable among all Sparcs. Isn't 'cas' an 8+ opcode?
So to use apr_atomic_sparc.s, at a minimum we need that.
--
===
Jim Jagielski [|] [
Jeff Trawick wrote:
Aaron Bannert <[EMAIL PROTECTED]> writes:
For example, I have a build of APR from an Ultra5 running Solaris 5.6
that produces sparcv8plus binaries. These binaries do not work on an
older SparcStation5 machine that is running Solaris 5.7.
I'm glad somebody else noticed this :)
Jeff Trawick wrote:
Aaron Bannert <[EMAIL PROTECTED]> writes:
For example, I have a build of APR from an Ultra5 running Solaris 5.6
that produces sparcv8plus binaries. These binaries do not work on an
older SparcStation5 machine that is running Solaris 5.7.
I'm glad somebody else noticed this :) I
On Thu, 25 Apr 2002, Aaron Bannert wrote:
| I was thinking that we could determine what the lowest-supported
| architecture was for each version of Solaris, and that would be the
| ISA that would be passed as -xarch. (Having an override would be fine,
| but I'm wholly against the building of non-p
On Thu, 25 Apr 2002, Aaron Bannert wrote:
| I've just come across a serious problem in the atomics autoconf
| code. Since we are detecting which sparc architecture the build is
| running on, and passing architecture-specific flags to the assembler,
| we are producing binaries that aren't backward-
On Thu, Apr 25, 2002 at 10:14:19PM -0400, Jeff Trawick wrote:
> > Is there still a way we can (automatically) produce atomics code while
> > preserving backward compatibility? At least we should be portable based
> > on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
> > machine out t
Aaron Bannert <[EMAIL PROTECTED]> writes:
> For example, I have a build of APR from an Ultra5 running Solaris 5.6
> that produces sparcv8plus binaries. These binaries do not work on an
> older SparcStation5 machine that is running Solaris 5.7.
I'm glad somebody else noticed this :) I had the fea
On Thu, Apr 25, 2002 at 06:56:13PM -0700, Aaron Bannert wrote:
> On Thu, Apr 25, 2002 at 05:54:35PM -0700, Justin Erenkrantz wrote:
> > How about just using the generic code for these types of situations?
> > Perhaps we need an --disable-atomic-asm flag that forces the generic
> > code to be used i
On Thu, Apr 25, 2002 at 05:54:35PM -0700, Justin Erenkrantz wrote:
> How about just using the generic code for these types of situations?
> Perhaps we need an --disable-atomic-asm flag that forces the generic
> code to be used instead of assembly code? -- justin
Unfortunately that still won't allo
On Thu, Apr 25, 2002 at 05:19:16PM -0700, Aaron Bannert wrote:
> I've just come across a serious problem in the atomics autoconf
> code. Since we are detecting which sparc architecture the build is
> running on, and passing architecture-specific flags to the assembler,
> we are producing binaries t
I've just come across a serious problem in the atomics autoconf
code. Since we are detecting which sparc architecture the build is
running on, and passing architecture-specific flags to the assembler,
we are producing binaries that aren't backward-compatible.
For example, I have a build of APR fro
17 matches
Mail list logo
