SPARC64: compiling Lazarus for (Debian 10) Linux

[MarkMLl]

I'm posting here so that it appears adjacent to @Praetor's discussion of SPARC, even if subsequently moved to one of the other FPC or Lazarus topics by a moderator.

I've disinterred a SPARC system so that I can check the behaviour of some libraries on a big-endian system. I can compile and run simple programs using FPC 3.2.2 for SPARC64, hosted on Debian 10 without multiarch. For completeness, I note that I also had some success with FPC 3.2.2 for 32-bit SPARC.

When trying to compile Lazarus 2.2.0 I get this:

Code: Text  [Select][+][-]

1. $ make LCL_PLATFORM=gtk2 all
2. make -C packager/registration
3. make[1]: Entering directory '/usr/local/share/lazarus-2.2.0+3.2.2/packager/registration'
4. /usr/bin/rm -f ../units/sparc64-linux/fcllaz.ppu
5. /usr/bin/mkdir -p ../units/sparc64-linux
6. /usr/local/bin/ppcsparc64 -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq -Fu. -Fu/usr/local/lib/fpc/3.2.2/units/sparc64-linux/rtl -FE. -FU../units/sparc64-linux -Fl/usr/lib/gcc/sparc64-linux-gnu/8 -dsparc64 fcllaz.pas
7. Hint: (11030) Start of reading config file /etc/fpc.cfg
8. Hint: (11031) End of reading config file /etc/fpc.cfg
9. Note: (11049) DWARF debug information cannot be used with smart linking with external assembler, disabling static library creation.
10. Free Pascal Compiler version 3.2.2 [2021/05/29] for sparc64
11. Copyright (c) 1993-2021 by Florian Klaempfl and others
12. (1002) Target OS: Linux for SPARC64
13. (3104) Compiling fcllaz.pas
14. (3104) Compiling lazaruspackageintf.pas
15. (9009) Assembling lazaruspackageintf
16. (9009) Assembling fcllaz
17. (1008) 124 lines compiled, 2.7 sec
18. (1022) 2 hint(s) issued
19. (1023) 1 note(s) issued
20. /usr/bin/cp -f Makefile.compiled ../units/sparc64-linux/FCL.compiled
21. make[1]: Leaving directory '/usr/local/share/lazarus-2.2.0+3.2.2/packager/registration'
22. make -C components/lazutils
23. ...
24. (3104) Compiling lazloggerdummy.pas
25. /usr/local/share/lazarus-2.2.0+3.2.2/components/lazutils/LazLoggerImpl.inc(11,3) Note: (6058) Call to subroutine "function GetDebugLogger:TLazLogger;" marked as inline is not inlined
26. /usr/local/share/lazarus-2.2.0+3.2.2/components/lazutils/LazLoggerImpl.inc(156,1) Fatal: Internal error 200408203
27. Fatal: (1018) Compilation aborted
28. make[1]: *** [Makefile:3294: lazutils.ppu] Error 1
29. make[1]: Leaving directory '/usr/local/share/lazarus-2.2.0+3.2.2/components/lazutils'
30. make: *** [Makefile:3714: lazutils] Error 2
31.  

I attach complete output. This is not "mission critical" for me but I suspect is a combination of platform/compiler against which Lazarus isn't checked on a regular basis.

MarkMLl

[AlexTP]

Free Pascal Compiler version 3.2.2 [2021/05/29] for sparc64
is too old, I guess...

[MarkMLl]

Free Pascal Compiler version 3.2.2 [2021/05/29] for sparc64
is too old, I guess...

Possibly. But allowing that it's the current stable version and works adequately on other platforms I think I'd prefer something a bit more definite rather than simply flailing around.

MarkMLl

[PascalDragon]

I attach complete output. This is not "mission critical" for me but I suspect is a combination of platform/compiler against which Lazarus isn't checked on a regular basis.

Can you try to reduce this problem? Judging from the internal error it has to do with some call preparation.

[MarkMLl]

Can you try to reduce this problem? Judging from the internal error it has to do with some call preparation.

I'm not sure, but I'm interested in helping out because I think having at least one viable big-endian target (possibly also with alignment requirements) is valuable. I'd rather not run this machine for too long though, even though small it's noisy and hot.

So far I've been able to compile various "ordinary" programs without error, it was only a full Lazarus build that gave problems... suggestions would be appreciated.

Would it be worth moving to FPC trunk? I've only got 3.2.2 for SPARC64 which would mean I'd have to try the version override hack, I'd rather not get back into the cross-compilation rabbithole since I've got impending bookkeeping for which I've earmarked the weekend.

MarkMLl

[PascalDragon]

I'm not sure, but I'm interested in helping out because I think having at least one viable big-endian target (possibly also with alignment requirements) is valuable.

For yourself or for FPC? Cause if the later we have the m68k and PPC targets which are in active use (at least more than the SPARC one is )

So far I've been able to compile various "ordinary" programs without error, it was only a full Lazarus build that gave problems... suggestions would be appreciated.

Try to extract the code that triggers the internal error into a separate program.

Would it be worth moving to FPC trunk? I've only got 3.2.2 for SPARC64 which would mean I'd have to try the version override hack, I'd rather not get back into the cross-compilation rabbithole since I've got impending bookkeeping for which I've earmarked the weekend.

Why would you need the version override option? You have a native 3.2.2 which is currently the last available release which means that's the only compiler that won't trigger the version check.

[MarkMLl]

I'm not sure, but I'm interested in helping out because I think having at least one viable big-endian target (possibly also with alignment requirements) is valuable.

For yourself or for FPC? Cause if the later we have the m68k and PPC targets which are in active use (at least more than the SPARC one is )

I'd forgotten there were active PPC users, but of course Marco mentioned it a few days ago. I agree that SPARC is about as dead as Queen Anne.

So far I've been able to compile various "ordinary" programs without error, it was only a full Lazarus build that gave problems... suggestions would be appreciated.

Try to extract the code that triggers the internal error into a separate program.

I'll see what I can do.

Would it be worth moving to FPC trunk? I've only got 3.2.2 for SPARC64 which would mean I'd have to try the version override hack, I'd rather not get back into the cross-compilation rabbithole since I've got impending bookkeeping for which I've earmarked the weekend.

Why would you need the version override option? You have a native 3.2.2 which is currently the last available release which means that's the only compiler that won't trigger the version check.

I thought the last version that would build it is 3.0?

MarkMLl

[MarkMLl]

I'm putting this one on the back burner for the moment, since some of the issues I can duplicate on x86_64 and appear to depend on the checks enabled (-C options)... and judging by their intermittent nature there might be something else cached outside the project tree which is making the problem very tricky to pin down.

MarkMLl

[PascalDragon]

I thought the last version that would build it is 3.0?

Huh? Why would we require something so ancient? main can always be built with the last release and (for a while after release at least) the version before that. So for 3.3.1 that is 3.2.2 and (for the time being) 3.2.0.

[MarkMLl]

I thought the last version that would build it is 3.0?

Huh? Why would we require something so ancient? main can always be built with the last release and (for a while after release at least) the version before that. So for 3.3.1 that is 3.2.2 and (for the time being) 3.2.0.

Sorry, mea culpa: I was still thinking in terms of building 3.2.

I've got to drop this for at least a few days to get some bookkeeping done. However I've eliminated one endianness issue from my code, which has left me with an intransigent exception which is compatible with your original suggestion that there might be a call preparation problem in 3.2.2.

I've also seen an odd problem where code would work differently depending on whether runtime checks were enabled. But I'm able to duplicate that- for some uncertain meaning of the word- on x86_64.

MarkMLl

[AlexTP]

Mark, it's interesting, does the TRegExpr (with my last changes: latest is here - https://github.com/alexey-T/tregexpr ) runs OK on SPARC? I mean it has the test/test_fpc.lpi .

[MarkMLl]

Mark, it's interesting, does the TRegExpr (with my last changes: latest is here - https://github.com/alexey-T/tregexpr ) runs OK on SPARC? I mean it has the test/test_fpc.lpi .

Sorry. I'll come back to this in a few days or a couple of weeks (and that's a promise). If it looks like I'm dragging my feet PM me a reminder.

I've got one SPARC system here, with a 64-bit Debian on it which looks half-decent (by the standards of SPARC Linux). What I need to do is get a comparable 32-bit implementation on the other disc, since historically FPC and Lazarus have run fairly well on that and it would provide a useful test combination.

MarkMLl