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/contrib/libgdb/v6.3/ and figured I'd try using them rather than ploughing my way through the toolchain sources which looked like a 60Mb download for Debian "Sarge". After a certain amount of trial and error I worked out that the files needed to be put in /fpcsrc/libgdb/linux for make to use them.

It looks as though the point at which they are initially used is OK:

make -C gdbint smart
make[4]: Entering directory `/fpcsrc/packages/base/gdbint' make all LINKSMART=1 CREATESMART=1
make[5]: Entering directory `/fpcsrc/packages/base/gdbint' /bin/mkdir -p units/sparc-linux
/fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -n -Fu/fpcsrc/rtl/units/sparc-linux -Fl/fpcsrc/libgdb/linux -Fo/fpcsrc/libgdb/linux -FE. -FUunits/sp /usr/bin/ar: creating units/sparc-linux/libpgdbver.a make gdbint.ppu GOTGDBVER=1
make[6]: Entering directory `/fpcsrc/packages/base/gdbint' Using GDB GDB_V603
/fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -n -Fu/fpcsrc/rtl/units/sparc-linux -Fl/fpcsrc/libgdb/linux -Fo/fpcsrc/libgdb/linux -FE. -FUunits/sp /bin/rm -f gdbver gdbver.o
make[6]: Leaving directory `/fpcsrc/packages/base/gdbint' /fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -n -Fu/fpcsrc/rtl/units/sparc-linux -Fl/fpcsrc/libgdb/linux -Fo/fpcsrc/libgdb/linux -FE. -FUunits/sp /usr/bin/ar: creating units/sparc-linux/libpgdbcon.a make[5]: Leaving directory `/fpcsrc/packages/base/gdbint' make[4]: Leaving directory `/fpcsrc/packages/base/gdbint'

(Sorry, that's slightly truncated by my telnet client).

However further on things go badly wrong:

/bin/mkdir -p /fpcsrc/ide/units/sparc-linux
/fpcsrc/compiler/ppcsparc -dBrowserCol -dGDB -Ur -Xs -n -Ur -dNOCATCH -Fu/fpcsrc/compiler -Fu/fpcsrc/compiler/sparc -Fu/fpcsrc/compiler/targes make[5]: Leaving directory `/fpcsrc/ide/compiler'
make[4]: Leaving directory `/fpcsrc/ide'
make testgdb
make[4]: Entering directory `/fpcsrc/ide'
LibGDB found in /fpcsrc/libgdb/linux/libgdb.a
make[4]: Leaving directory `/fpcsrc/ide'
make fpc_all
make[4]: Entering directory `/fpcsrc/ide'
/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':
/mnt/hda1/florian/gdb-6.3.woody/gdb/gdbtypes.c:752: undefined reference to `__muldi3'
/fpcsrc/libgdb/linux/libgdb.a(ada-lang.o)(.text+0x1098): In function `max_of_size':
/mnt/hda1/florian/gdb-6.3.woody/gdb/ada-lang.c:519: undefined reference to `__ashldi3'

And so on. The obvious questions are:

i) Are precompiled binaries of the gdb interface library available for Debian Sarge? So far I can't track down an appropriate standard package.

ii) Can I compile them myself without breaking my toolchain, and if so what configure parameters etc. do I need?

iii) What am I missing that is blindingly obvious? :-)

This can normally be solved by linking in libgcc. Try adding {$l gcc} to the gdbint unit.

Jonas

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 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

Jonas is right. Sorry, this is undocumented behaviour. Undocumented on purpose, so there is a fair chance it might change in the future.

OK, noted. However if it gets me out of the initial hole it's a very good start.

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 the source to pick it up?

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).

Jonas

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 reference. I was assuming that the addition was to the FPC stuff rather than the toolchain.

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?

No, it should require libgcc.a, which should be installed on your system already.

Jonas

In a later msg you say {$l gcc} instead of {$linklib gcc}.

It should be the latter.

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

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...

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 telling me that it can't find the library version it was built against. I'm going to drop that as an experiment since that machine is too ponderous to build the compiler in less than a day, and upgrading anything on it isn't feasible.

Going back to the SEGV problem, is there any way that somebody with my minimal experience can tackle this?

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) before linking.

Some more tips (just ideas): Only IDE (fp) should be using libc (assuming we talk about Linux target), so only building that one on the target machine (make all in the IDE directory) should reduce the building time. Finally, it might be possible to build everything on the build machine (again use -s option when building, remove all "rm" commands from the generated ppas.sh before running it and possibly skip the linker too), transfer everything to target machine and relink there.

Going back to the SEGV problem, is there any way that somebody with my minimal experience can tackle this?

Possibly. You might try it with debug info (and line info) enabled binary to get backtrace. That might possibly help to shed some light on what's happening there at least; of course it doesn't automatically mean that it gets resolved, but there's a chance.

Tomas

Usual unix library mess. Transfering binaries from one machine to another is often a problem.

Compile the IDE with GDB support (make clean all OPT=-g) run it inside GDB and post the stack trace:

gdb ./fp
r
where

I'm going to drop working on the larger machine for the moment, I've just checked and a basic "Hello World" works on it which is obviously a good starting point. I will need to use it if I get as far as testing against Solaris 8 (I hope to have Solaris 10 running on newer hardware, but am still trying to fit in time to go collect it). I mean let's face it- what relevance is something with 8x 50MHz CPUs these days? :-)

OK, that looks pretty good but any suggestions as to how I get the compiler options in? Can I give make a -D, or do I need to break into the make process in some way I don't yet understand, and how can I check that the generated binary is in the intended state once it's built?

Ah- OK, I think I get that. Back in a few hours... :-)

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 truncated (can I redirect this without messing up the IDE?).

Program received signal SIGSEGV, Segmentation fault. 0x000322d4 in TRY_CONCAT_FREE_CHUNK (MC=0x502b3880) at heap.inc:679 679 heap.inc: No such file or directory.
in heap.inc
(gdb) where
#0 0x000322d4 in TRY_CONCAT_FREE_CHUNK (MC=0x502b3880) at heap.inc:679 #1 0x00033114 in SYSFREEMEM_VAR (PCURR=0x502b3880) at heap.inc:1023 #2 0x000331c8 in SYSFREEMEM (P=0x502b3888) at heap.inc:1043 #3 0x0003134c in FREEMEM (P=0x502b3888) at heap.inc:325 #4 0x00015a54 in fpc_help_destructor (_SELF=0x502b3888, _VMT=0x538b8c, VMT_POS=0) at generic.inc:419
#5 0x000a6c00 in TLINE__DONE (vmt=0x538b8c, this={<TCUSTOMLINE> = {<TOBJECT> = {_vptr$ = {0x505fd320, 0x0}}, }, TEXT = 0x0, DEFAULTEDITORINFO = 0x0, EDITORINFOS = 0x0, FLAGS = 0, OWNER = 0x502c2d48}) at wcedit.pas:366 #6 0x0004f628 in TCOLLECTION__FREEITEM (ITEM=0x502b3888, this={<TOBJECT> = {_vptr$ = {0x55015c, 0x505fbb38}}, ITEMS = 0x505fbb38, COUNT = 50, LIMIT = 500, DELTA = 1000}) at objects.pp:2018
#7 0x0004f498 in TCOLLECTION__FREEALL (this={<TOBJECT> = {_vptr$ = {0x55015c, 0x505fbb38}}, ITEMS = 0x505fbb38, COUNT = 50, LIMIT = 500, DELTA = 1000}) at objects.pp:1963
#8 0x0004ef38 in TCOLLECTION__DONE (vmt=0x55015c, this={<TOBJECT> = {_vptr$ = {0x55015c, 0x505fbb38}}, ITEMS = 0x505fbb38, COUNT = 50, LIMIT = 500, DELTA = 1000}) at objects.pp:1862
#9 0x000a84f8 in TCODEEDITORCORE__DONE (vmt=0x538bbc, this= {<TCUSTOMCODEEDITORCORE> = {<TOBJECT> = {_vptr$ = {0x538bbc, 0x0}}, BINDINGS = 0x0, LOCKFLAG = 0, CHANGEDLINE = 0, CONTENTSCHANGEDCALLED = false, LIMITSCHANGEDCALLED = false, MODIFIEDCHANGEDCALLED = false, TABSIZECHANGEDCALLED = false, STOREUNDOCHANGEDCALLED = false, LASTSYNTAXEDLINE = 49, SY2
#10 0x000abe1c in TCODEEDITOR__DONE (vmt=0x0, this={<TCUSTOMCODEEDITOR> = {<TSCROLLER> = {<TVIEW> = {<TOBJECT> = {_vptr$ = {0x55018c, 0xc200000}}, GROWMODE = 12, DRAGMODE = 32, TABMASK = 0, COLOUROFS = 0, HELPCTX = 0, STATE = 2, OPTIONS = 1, EVENTMASK = 785, ORIGIN = {X = 1, Y = 1}, SIZE = {X = 130, Y = 145}, CURSOR = {X = 0, Y = 20}, NEXT = 5 #11 0x000ee250 in TDISASSEMBLYEDITOR__DONE (vmt=0x55018c, this={<TSOURCEEDITOR> ={<TFILEEDITOR> = {<TCODEEDITOR> = {<TCUSTOMCODEEDITOR> = {<TSCROLLER> = {<TVIEW> = {<TOBJECT> = {_vptr$ = {0x55018c, 0xc200000}}, GROWMODE = 12, DRAGMODE = 32, TABMASK = 0, COLOUROFS = 0, HELPCTX = 0, STATE = 2, OPTIONS = 1, EVENTMASK = 785, ORIGIN = {X = 1, Y = 1}, SIZE = 9

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, although there's a SEGV during Lazarus startup and possibly other errors- the same combination of FPC/Lazarus is OK on Linux/i386 subject to not having libgdb.

It turns out that this problem is entirely to do with the fp debugger interface. If I build fp without debugger support then I can move it between machines and it runs reliably on both, but if I incorporate the debugger interface I get the failure described above.

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 the machine (Debian "Sarge") I'm using for the build /lib/libc.so.6 -> libc-2.3.2.so, on the older machine (Debian "Woody") /lib64/libc.so.6 -> libc-2.2.5.so.

If you leave out the debugger interface, libc is left out which isn't required then. Transfering binaries between linuxes using different libc is always random if it works or not.

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.

Much what I'd concluded. I think it leaves me in the position of having to build the gcc toolchain so that I've got the gdb interface libraries that match my development machine before I try any further debugging of the debugger-interface segv.

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 slower/hotter/noisier :-)

On the other hand, what you say implies that it might be possible to build the gdb interface libraries on a Woody system and than use them on Sarge et al., otherwise do you have any thoughts on the best way to build/obtain them since I sind the thought of loading and building the entire GNU toolchain somewhat daunting :-/

Still avoidable, I'd say:

1) make all (to have the other packages compiled _and_ assembled)
2) cd ide
3) rm fp
4) make all "OPT=-s" (without cleaning the compiled units)
5) transfer the whole tree to the target (=slow) machine and run ppas.sh there

Tomas

Thanks Tomas, I'll take a look if possible but at present I'm working on dataabse problems.