On 17-7-2012 22:20, Mark Morgan Lloyd wrote:
> Mark Morgan Lloyd wrote:
>> Sven Barth wrote:
>>
> Now, you are getting a SIGSEGV, not a SIGBUS which is what you would
> get for
> an alignment problem.
This problem no longer exists in 2.7.1 (21919 + Reinier's
solarisdbtrun
Mark Morgan Lloyd wrote:
Sven Barth wrote:
Now, you are getting a SIGSEGV, not a SIGBUS which is what you would
get for
an alignment problem.
This problem no longer exists in 2.7.1 (21919 + Reinier's
solarisdbtrunk2.diff).
Then it might be good if you report this in Mantis together with
Re
Sven Barth wrote:
Now, you are getting a SIGSEGV, not a SIGBUS which is what you would
get for
an alignment problem.
This problem no longer exists in 2.7.1 (21919 + Reinier's
solarisdbtrunk2.diff).
Then it might be good if you report this in Mantis together with
Reinier's patch so that it i
Am 17.07.2012 11:12, schrieb Mark Morgan Lloyd:
Ludo Brands wrote:
We only support 32 bit SPARC, and there we split a 64 bit load into two
32 bit loads. dbl, assuming it points to a double, should
point to a 64
bit-aligned memory location though (depending on the cpu, 32 bit
alignment may be s
Ludo Brands wrote:
We only support 32 bit SPARC, and there we split a 64 bit load into
two
32 bit loads. dbl, assuming it points to a double, should
point to a 64
bit-aligned memory location though (depending on the cpu, 32 bit
alignment may be sufficient, but better be safe than sorry).
I'll
On Mon, 16 Jul 2012 13:49:13 +
Mark Morgan Lloyd wrote:
>[...]
> > Remove the ibconnection unit or put it in an {$IFNDEF SOLARIS}. (or should
> > that be SUNOS ?)
> >
> > You'll have to remove TIBConnection from the registercomponents call as
> > well.
> >
> > If that works, we'll put it in
michael.vancann...@wisa.be wrote:
On Mon, 16 Jul 2012, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
[Nod], understood. Hit a slight snag here with trunk FPC + trunk
Lazarus:
Target OS: Solaris for SPARC
Compiling sqldblaz.pas
Compiling registersqldb.pas
registersqldb.pas(58,3) Fatal: C
On 16 July 2012 12:16, wrote:
>
> I don't think Firebird works on Solaris or SPARC cpus, so it makes no sense
> to compile in firebird support on that platform.
Wrong!
>From the Firebird website: "Firebird 2.5 runs on Windows (32- and
64-bit), various Linux versions (32- and 64- bit), Solaris
On Mon, 16 Jul 2012, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
[Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus:
Target OS: Solaris for SPARC
Compiling sqldblaz.pas
Compiling registersqldb.pas
registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used b
Mark Morgan Lloyd wrote:
[Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus:
Target OS: Solaris for SPARC
Compiling sqldblaz.pas
Compiling registersqldb.pas
registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by
registersqldb
Fatal: Compilation aborted
make[
Ludo Brands wrote:
We only support 32 bit SPARC, and there we split a 64 bit load into
two
32 bit loads. dbl, assuming it points to a double, should
point to a 64
bit-aligned memory location though (depending on the cpu, 32 bit
alignment may be sufficient, but better be safe than sorry).
I'll
> > We only support 32 bit SPARC, and there we split a 64 bit load into
> > two
> > 32 bit loads. dbl, assuming it points to a double, should
> point to a 64
> > bit-aligned memory location though (depending on the cpu, 32 bit
> > alignment may be sufficient, but better be safe than sorry).
>
In our previous episode, Jonas Maebe said:
>
> > I'll try to test against 2.7.1 later in the day, although as I've
> > said Linux is OK.
>
> The memory layout is not necessarily the same on both OSes.
Or does the linux kernel contain a facility to work around certain kinds of
exceptions?
E.g.
Mark Morgan Lloyd wrote on Thu, 12 Jul 2012:
I'll try to test against 2.7.1 later in the day, although as I've
said Linux is OK.
The memory layout is not necessarily the same on both OSes.
Is the if FIntegerDatetimes then something Solaris-specific Ludo?)?
That would be extremely unlik
Jonas Maebe wrote:
Thomas Schatzl wrote on Thu, 12 Jul 2012:
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0,
FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc,
Thomas Schatzl wrote on Thu, 12 Jul 2012:
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0,
FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa
803
Thomas Schatzl wrote:
Hi,
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
Ludo Brands wrote:
Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a
consistent error
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LO
Hi,
On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote:
> Ludo Brands wrote:
>
> Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a
> consistent error
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 4]
> 0x004b08b8 in TPQCONNECTION__LOADFIELD (CU
Ludo Brands wrote:
I've found a problem when a (well-tested) program that connects to a
PostgreSQL database is compiled and run on Solaris 10 for
SPARC, Linux
SPARC is OK.
I appreciate that this is a minority platform, but would I be less
unpopular reporting it against 2.6.0 or testing it ag
> I've found a problem when a (well-tested) program that connects to a
> PostgreSQL database is compiled and run on Solaris 10 for
> SPARC, Linux
> SPARC is OK.
>
> I appreciate that this is a minority platform, but would I be less
> unpopular reporting it against 2.6.0 or testing it against
Am 12.07.2012 10:11 schrieb "Mark Morgan Lloyd" <
markmll.fpc-pas...@telemetry.co.uk>:
>
> I've found a problem when a (well-tested) program that connects to a
PostgreSQL database is compiled and run on Solaris 10 for SPARC, Linux
SPARC is OK.
>
> I appreciate that this is a minority platform, but
21 matches
Mail list logo
