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.
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
13 matches
Mail list logo