Thanks Tomas, I'll take a look if possible but at present I'm working on
dataabse problems.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist -
Mark Morgan Lloyd wrote:
> Peter Vreman wrote:
>
>> libc is backwards compatible only. That means you can build something
>> with
>> libc-2.2.5 and it will run also on libc-2.3.2. So a fp with debugger
>> build
>> on Woody will also run on Sarge, Etch and Sid.
>
> Thanks Peter, noted. However I'm t
Peter Vreman wrote:
> libc is backwards compatible only. That means you can build something with
> libc-2.2.5 and it will run also on libc-2.3.2. So a fp with debugger build
> on Woody will also run on Sarge, Etch and Sid.
Thanks Peter, noted. However I'm trying to move to faster hardware, not
sl
Florian Klaempfl wrote:
> > I'm still working on other things but that leaves me wondering whether
> > there's scope for the main part of fp and the gdb interface to attempt to
> > use incompatible library versions at runtime. On the machine (Debian
> > "Sarge") I'm using for the build /lib/libc.s
>> I'm still working on other things but that leaves me wondering whether
>> there's
>> scope for the main part of fp and the gdb interface to attempt to use
>> incompatible library versions at runtime. On the machine (Debian
>> "Sarge") I'm
>> using for the build /lib/libc.so.6 -> libc-2.3.2.so, o
Mark Morgan Lloyd wrote:
Tomas Hajny wrote:
I find I can't transfer the compiled bundle to another machine- I get "fp:
/lib/libc.so.6: version `GLIBC_2.3' not found (required by fp)" which I
presume is telling me that it can't find the library version it was built
against. I'm going to drop tha
Tomas Hajny wrote:
> > I find I can't transfer the compiled bundle to another machine- I get "fp:
> > /lib/libc.so.6: version `GLIBC_2.3' not found (required by fp)" which I
> > presume is telling me that it can't find the library version it was built
> > against. I'm going to drop that as an expe
I'm going to have to drop FPC on SPARC for a few days since I've got a job that
needs to be done for the end of the month.
The position appears to be that the compiler and much of the IDE is reliable,
with the exception of some window operations. The compiler is good enough to
compile Lazarus, alt
Florian Klaempfl wrote:
> Compile the IDE with GDB support (make clean all OPT=-g) run it inside GDB and
> post the stack trace:
>
> gdb ./fp
> r
> where
OK, I think it's reproducible. Simple program, to build and step, open
disassembly window, close and SEGV. First few lines of output, slightl
Florian Klaempfl wrote:
> Compile the IDE with GDB support (make clean all OPT=-g) run it inside GDB and
> post the stack trace:
>
> gdb ./fp
> r
> where
Ah- OK, I think I get that. Back in a few hours... :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the auth
Tomas Hajny wrote:
> I guess that you could still use the cross-compilation trick - bring the
> library from the target machine to your build machine and change the
> search paths (probably manually - using "-s" option and playing with the
> generated script.res before running the created ppas.sh)
Mark Morgan Lloyd wrote:
The build worked and I appear to have an intact fpc and fp. However fp's
disassembly window is very fragile- SEGV at the drop of a hat.
I find I can't transfer the compiled bundle to another machine- I get "fp:
/lib/libc.so.6: version `GLIBC_2.3' not found (required by f
Mark Morgan Lloyd wrote:
> The build worked and I appear to have an intact fpc and fp. However fp's
> disassembly window is very fragile- SEGV at the drop of a hat.
>
> I find I can't transfer the compiled bundle to another machine- I get "fp:
> /lib/libc.so.6: version `GLIBC_2.3' not found (requir
The build worked and I appear to have an intact fpc and fp. However fp's
disassembly window is very fragile- SEGV at the drop of a hat.
I find I can't transfer the compiled bundle to another machine- I get "fp:
/lib/libc.so.6: version `GLIBC_2.3' not found (required by fp)" which I presume
is tell
Jonas Maebe wrote:
> > In a later msg you say {$l gcc} instead of {$linklib gcc}.
>
> Ah yes, of course.
Yes, I was looking at that commented-out line. I've set another build going,
I'll be back in about six hours...
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are
On 15 Aug 2006, at 09:35, Marco van de Voort wrote:
No, it should require libgcc.a, which should be installed on your
system already.
In a later msg you say {$l gcc} instead of {$linklib gcc}.
Ah yes, of course.
Jonas
___
fpc-pascal maillist -
> On 14 Aug 2006, at 23:58, Mark Morgan Lloyd wrote:
>
> >> OK, noted for reference. I was assuming that the addition was to
> >> the FPC stuff
> >> rather than the toolchain.
> >
> > Requires gcc.o, which I presume implies that the entire toolchain
> > has to be on
> > the system. Can I gener
On 14 Aug 2006, at 23:58, Mark Morgan Lloyd wrote:
OK, noted for reference. I was assuming that the addition was to
the FPC stuff
rather than the toolchain.
Requires gcc.o, which I presume implies that the entire toolchain
has to be on
the system. Can I generate that without risking brea
Mark Morgan Lloyd wrote:
> OK, noted for reference. I was assuming that the addition was to the FPC stuff
> rather than the toolchain.
Requires gcc.o, which I presume implies that the entire toolchain has to be on
the system. Can I generate that without risking breaking things?
--
Mark Morgan L
Jonas Maebe wrote:
> The {$l gcc} does not have to be added to the GNU toolchain sources,
> only to our interfacing unit with libgdb (namely packages/base/gdbint/
> gdbint.pp). And only for certain platforms that need it (not all of
> them do, which is why it isn't there yet).
OK, noted for refer
On 14 aug 2006, at 14:46, Mark Morgan Lloyd wrote:
What is the correct solution to the problem, and allowing for the
fact that the
available binary libgdb was SPARC where does this leave somebody
building for
another architecture- do they need to compile the full GNU
toolchain then patch
Marco van de Voort wrote:
> > > -XLAc=c,gcc
> > >
> > > in your fpc.cfg to fix similar cases globally.
> >
> > I thought this was not supposed to be publicised/encouraged? (and
> > that for that reason you didn't add this option to the help pages?)
>
> Jonas is right. Sorry, this is undocumente
> On 14 aug 2006, at 13:20, Marco van de Voort wrote:
> >> This can normally be solved by linking in libgcc. Try adding {$l gcc}
> >> to the gdbint unit.
> >
> > 2.0.4's and recent 2.1.1/2.0.3's, (rougly all versions since mid-
> > end june),
> > put
> >
> > -XLAc=c,gcc
> >
> > in your fpc.cfg
On 14 aug 2006, at 13:20, Marco van de Voort wrote:
This can normally be solved by linking in libgcc. Try adding {$l gcc}
to the gdbint unit.
2.0.4's and recent 2.1.1/2.0.3's, (rougly all versions since mid-
end june),
put
-XLAc=c,gcc
in your fpc.cfg to fix similar cases globally.
I
> On 14 aug 2006, at 12:21, Mark Morgan Lloyd wrote:
>
> > /fpcsrc/compiler/ppcsparc -Fl/fpcsrc/libgdb/linux -Ur -Xs -n -Sg
> > -Fu/fpcsrc/rtl/units/sparc-linux -Fu/fpcsrc/fv/units/sparc-linux -
> > Fu/fpcsrc/s
> > /fpcsrc/libgdb/linux/libgdb.a(gdbtypes.o)(.text+0x1154): In function
> > `cre
On 14 aug 2006, at 12:21, Mark Morgan Lloyd wrote:
/fpcsrc/compiler/ppcsparc -Fl/fpcsrc/libgdb/linux -Ur -Xs -n -Sg
-Fu/fpcsrc/rtl/units/sparc-linux -Fu/fpcsrc/fv/units/sparc-linux -
Fu/fpcsrc/s
/fpcsrc/libgdb/linux/libgdb.a(gdbtypes.o)(.text+0x1154): In function
`create_array_type':
/mn
I think I've worked out how to build fpc and fp 2.0.4 for SPARC starting off
from 2.0.0, many thanks in particular to Jonas. The next question, before I try
moving the result to a virgin machine, is how to add gdb support.
I eventually found the libraries at
ftp://ftp.freepascal.org/pub/fpc/contri
27 matches
Mail list logo
