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
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 that
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 allow
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 instead
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 fear
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 there).
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
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
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 :)
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 [|]
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.
--
===
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
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
13 matches
Mail list logo
