Forum > Other
SPARC64: compiling Lazarus for (Debian 10) Linux
PascalDragon:
--- Quote from: MarkMLl on June 17, 2022, 10:07:54 am ---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.
--- End quote ---
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 ;) )
--- Quote from: MarkMLl on June 17, 2022, 10:07:54 am ---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.
--- End quote ---
Try to extract the code that triggers the internal error into a separate program.
--- Quote from: MarkMLl on June 17, 2022, 10:07:54 am ---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.
--- End quote ---
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:
--- Quote from: PascalDragon on June 17, 2022, 01:31:25 pm ---
--- Quote from: MarkMLl on June 17, 2022, 10:07:54 am ---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.
--- End quote ---
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 ;) )
--- End quote ---
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.
--- Quote ---
--- Quote from: MarkMLl on June 17, 2022, 10:07:54 am ---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.
--- End quote ---
Try to extract the code that triggers the internal error into a separate program.
--- End quote ---
I'll see what I can do.
--- Quote ---
--- Quote from: MarkMLl on June 17, 2022, 10:07:54 am ---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.
--- End quote ---
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.
--- End quote ---
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:
--- Quote from: MarkMLl on June 17, 2022, 01:43:08 pm ---I thought the last version that would build it is 3.0?
--- End quote ---
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:
--- Quote from: PascalDragon on June 19, 2022, 01:19:08 pm ---
--- Quote from: MarkMLl on June 17, 2022, 01:43:08 pm ---I thought the last version that would build it is 3.0?
--- End quote ---
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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page