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 experiment
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 that
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, on the older
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
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 trying to move
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 -
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,
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
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
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 author's,
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, F7 to build and step, open
disassembly window, close and SEGV. First few lines of output, slightly
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
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 -
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 the
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
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
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':
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
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 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
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 undocumented behaviour.
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
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
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
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
25 matches
Mail list logo
