[fpc-devel] Porting fpc to linux-sparc64

[John Paul Adrian Glaubitz]

Hi!

I'm one of Debian's sparc64 porters and we're currently in the process of
getting the sparc64 port back in shape so it can part of the official release,
superceding Debian's old sparc port.

Naturally, I was trying to bootstrap fpc for Debian/sparc64. However, I noticed
that - despite supporting the SPARCV9 target - fpc is tied to 32-bit SPARC
only.

When trying to cross-build fpc for sparc64, I ran into linker issues. I was
able to resolve these when changing the ELF format from 32 to 64 bits in
compiler/system/t_linux.pas and changing the dynamic loader path from
/lib/ld-linux.so.2 to /lib64/ld-linux.so.2. However, trying to run these
binaries on an actual sparc64 box running Debian unstable results in bus errors.

Thus, I was wondering whether there are still people around who care for the
SPARC port of fpc and who could help me. We have very fast sparc64 porterboxes
available running Debian unstable and I'd be happy to create accounts on these
machines for anyone who wants to help.

Thanks,
Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz
When trying to cross-build fpc for sparc64, I ran into linker issues. I was
able to resolve these when changing the ELF format from 32 to 64 bits in
compiler/system/t_linux.pas and changing the dynamic loader path from
/lib/ld-linux.so.2 to /lib64/ld-linux.so.2. However, trying to run these
binaries on an actual sparc64 box running Debian unstable results in bus errors.

Hmm, we had the last testsuite run for SPARC Linux back in 2013. I was
under the impression it's still being tested... The Solaris version's last
testresult is from 2012...

https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=150744
https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=120817

Which might suggest that the trunk could be broken at this point. :(
And/or completely unprepared for 64bit in any way. Although we still seem
to have a stable 3.0.2 release. Can you try if the stable release built by
us works on your system? Any binary from this.

ftp://ftp.freepascal.org/pub/fpc/dist/3.0.2/sparc-linux/

Post by John Paul Adrian Glaubitz
Thus, I was wondering whether there are still people around who care for the
SPARC port of fpc and who could help me. We have very fast sparc64 porterboxes
available running Debian unstable and I'd be happy to create accounts on these
machines for anyone who wants to help.

I don't know anything about SPARC, but if no one else volunteers, I can
take a look. In fact, maybe even a full 64bit SPARC port shouldn't be that
hard (famous last words...), but at least a few weeks of work for sure for
someone who knows the compiler internals.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-de

[John Paul Adrian Glaubitz]

Hi!

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
When trying to cross-build fpc for sparc64, I ran into linker issues. I was
able to resolve these when changing the ELF format from 32 to 64 bits in
compiler/system/t_linux.pas and changing the dynamic loader path from
/lib/ld-linux.so.2 to /lib64/ld-linux.so.2. However, trying to run these
binaries on an actual sparc64 box running Debian unstable results in bus errors.

Hmm, we had the last testsuite run for SPARC Linux back in 2013. I was
under the impression it's still being tested... The Solaris version's last
testresult is from 2012...
https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=150744
https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=120817

Aha.

Post by Karoly Balogh (Charlie/SGR)
Which might suggest that the trunk could be broken at this point. :(

The build actually succeeds with the modifications I made.

Post by Karoly Balogh (Charlie/SGR)
And/or completely unprepared for 64bit in any way.

I actually don't think there would be much work necessary. fpc already
supports SPARCv9 which is actually by default a 64-bit architecture
(also known as UltraSPARC).

However, most Linux distributions compiled SPARCv9 binaries with
"-m32" in the past and that was also the default configuration for
Debian's old "sparc" port which was dropped in 2015 after Debian
Wheezy.

Debian's new sparc64 port is effectively the same code (SPARCv9), just
with the "-m32" option removed. Depending on how much fpc depends on
pointer and default word sizes, it may just be a matter of extending
all pointers and default words to 64 bits.

Post by Karoly Balogh (Charlie/SGR)
Although we still seem to have a stable 3.0.2 release. Can you try
if the stable release built by us works on your system? Any binary
from this.
ftp://ftp.freepascal.org/pub/fpc/dist/3.0.2/sparc-linux/

Running the IDE (fp) and the compiler (ppcsparc) works, although I did
not perform any extensive tests:

***@deb4g:~/fpc-3.0.2$ ./lib/fpc/3.0.2/ppcsparc
Free Pascal Compiler version 3.0.2 [2017/05/07] for sparc
Copyright (c) 1993-2017 by Florian Klaempfl and others
/home/glaubitz/fpc-3.0.2/lib/fpc/3.0.2/ppcsparc [options] <inputfile>
[options]
Put + after a boolean switch option to enable it, - to disable it.
(...)

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
Thus, I was wondering whether there are still people around who care for the
SPARC port of fpc and who could help me. We have very fast sparc64 porterboxes
available running Debian unstable and I'd be happy to create accounts on these
machines for anyone who wants to help.

I don't know anything about SPARC, but if no one else volunteers, I can
take a look. In fact, maybe even a full 64bit SPARC port shouldn't be that
hard (famous last words...), but at least a few weeks of work for sure for
someone who knows the compiler internals.

I also don't think it will be that hard given the fact that the
important part, a code generator for SPARCv9, is already in place.

I can also provide a machine that could be used for running the
testsuite on Linux/sparc64. We already provide such a machine for the
QEMU upstream developers to test on sparc64.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Although we still seem to have a stable 3.0.2 release. Can you try
if the stable release built by us works on your system? Any binary
from this.
ftp://ftp.freepascal.org/pub/fpc/dist/3.0.2/sparc-linux/

Running the IDE (fp) and the compiler (ppcsparc) works, although I did
Free Pascal Compiler version 3.0.2 [2017/05/07] for sparc
Copyright (c) 1993-2017 by Florian Klaempfl and others
/home/glaubitz/fpc-3.0.2/lib/fpc/3.0.2/ppcsparc [options] <inputfile>
[options]
Put + after a boolean switch option to enable it, - to disable it.
(...)

Trying to build fpc with the pre-compiled binaries fails with said
linker issues:

make[6]: Entering directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc/compiler'
/usr/bin/ppcsparc -Ur -Xs -O2 -n -Fusparc -Fusystems -Fu/root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux -Fisparc -FE. -FUsparc/units/sparc-linux -dRELEASE @/root/fpcp
/usr/bin/ld: warning: ./link.res contains output sections; did you forget -T?
/usr/bin/ld: skipping incompatible /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o when searching for /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/pro
/usr/bin/ld: cannot find /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o
/usr/bin/ld: skipping incompatible sparc/units/sparc-linux/msg2inc.o when searching for sparc/units/sparc-linux/msg2inc.o
/usr/bin/ld: skipping incompatible ./sparc/units/sparc-linux/msg2inc.o when searching for sparc/units/sparc-linux/msg2inc.o
/usr/bin/ld: cannot find sparc/units/sparc-linux/msg2inc.o
/usr/bin/ld: skipping incompatible /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/system.o when searching for /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/o
/usr/bin/ld: cannot find /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/system.o
/usr/bin/ld: skipping incompatible /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/strings.o when searching for /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linuxo
/usr/bin/ld: cannot find /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/strings.o
msg2inc.pp(810,51) Error: Error while linking
msg2inc.pp(810,51) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Makefile:3858: recipe for target 'msg2inc' failed
make[6]: *** [msg2inc] Error 1
make[6]: Leaving directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc/compiler'
Makefile:3860: recipe for target 'msgtxt.inc' failed
make[5]: *** [msgtxt.inc] Error 2
make[5]: Leaving directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc/compiler'
Makefile:3973: recipe for target 'next' failed
make[4]: *** [next] Error 2
make[4]: Leaving directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc/compiler'
Makefile:3978: recipe for target 'ppc1' failed
make[3]: *** [ppc1] Error 2
make[3]: Leaving directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc/compiler'
Makefile:3990: recipe for target 'cycle' failed
make[2]: *** [cycle] Error 2
make[2]: Leaving directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc/compiler'
Makefile:2783: recipe for target 'compiler_cycle' failed
make[1]: *** [compiler_cycle] Error 2
make[1]: Leaving directory '/root/fpc/fpc-3.0.0+dfsg/fpcsrc'
debian/rules:304: recipe for target 'build-arch-stamp' failed
make: *** [build-arch-stamp] Error 2
***@deb4g:~/fpc/fpc-3.0.0+dfsg#

Running the file utility on one of the object files shows that the
assembler did not generate 32-bit code. So, at least a hotfix here
would be to pass "-m32" to the assembler.

***@deb4g:~/fpc/fpc-3.0.0+dfsg# file /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/strings.o
/root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/strings.o: ELF 64-bit MSB relocatable, SPARC V9, relaxed memory ordering, version 1 (SYSV), not stripped
***@deb4g:~/fpc/fpc-3.0.0+dfsg#

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz
Running the file utility on one of the object files shows that the
assembler did not generate 32-bit code. So, at least a hotfix here
would be to pass "-m32" to the assembler.

That is easy to add, see in compiler/sparc/cpugas.pas, MakeCmdLine method,
which works from the templates at the bottom of the same file. However,
this always asks the question, what would happen with other platforms,
like does this -m32 change breaks 32bit SPARC and/or some distros/older
versions of binutils? Otherwise I can add it permanently, it's no biggie.

You can also try to add the OPT="-ao-m32" option to the build to see if
that indeed works (or CROSSOPT="-ao-m32" in case of crossbuilds).

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/f

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
Running the file utility on one of the object files shows that the
assembler did not generate 32-bit code. So, at least a hotfix here
would be to pass "-m32" to the assembler.

That is easy to add, see in compiler/sparc/cpugas.pas, MakeCmdLine method,
which works from the templates at the bottom of the same
file.

Good idea, I'll try that.

Post by Karoly Balogh (Charlie/SGR)
However, this always asks the question, what would happen with other
platforms, like does this -m32 change breaks 32bit SPARC and/or some
distros/older versions of binutils? Otherwise I can add it
permanently, it's no biggie.

You're already doing that for the linker, using the GNU option
syntax. So, I don't think the code becomes any less compatible with
that change.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
Running the file utility on one of the object files shows that the
assembler did not generate 32-bit code. So, at least a hotfix here
would be to pass "-m32" to the assembler.

That is easy to add, see in compiler/sparc/cpugas.pas, MakeCmdLine method,
which works from the templates at the bottom of the same
file.

Good idea, I'll try that.

I tried adding "-32" like this:

Index: fpc-3.0.0+dfsg/fpcsrc/compiler/sparc/cpugas.pas
===================================================================
--- fpc-3.0.0+dfsg.orig/fpcsrc/compiler/sparc/cpugas.pas
+++ fpc-3.0.0+dfsg/fpcsrc/compiler/sparc/cpugas.pas
@@ -77,7 +77,7 @@ implementation
cpu_SPARC_V7: Replace(result,'$ARCH','-Av7');
cpu_SPARC_V8: Replace(result,'$ARCH','-Av8')
else
- Replace(result,'$ARCH','-Av9')
+ Replace(result,'$ARCH','-Av9 -32')
end
end;

@@ -226,7 +226,7 @@ implementation
{$ifdef FPC_SPARC_V8_ONLY}
asmcmd : '$PIC -o $OBJ $EXTRAOPT $ASM';
{$else}
- asmcmd : '$ARCH $PIC -o $OBJ $EXTRAOPT $ASM';
+ asmcmd : '$ARCH $PIC -o $OBJ -32 $EXTRAOPT $ASM';
{$endif}
supported_targets : [system_sparc_solaris,system_sparc_linux,system_sparc_embedded];
flags : [af_needar,af_smartlink_sections];
@@ -240,7 +240,7 @@ implementation
id : as_ggas;
idtxt : 'GAS';
asmbin : 'gas';
- asmcmd : '$ARCH $PIC -o $OBJ $EXTRAOPT $ASM';
+ asmcmd : '$ARCH $PIC -o $OBJ -32 $EXTRAOPT $ASM';
supported_targets : [system_sparc_solaris,system_sparc_linux,system_sparc_embedded];
flags : [af_needar,af_smartlink_sections];
labelprefix : '.L';

Still generates 64-bit object files:

***@deb4g:~/fpc/fpc-3.0.0+dfsg# file /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/strings.o
/root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/strings.o: ELF 64-bit MSB relocatable, SPARC V9, relaxed memory ordering, version 1 (SYSV), not stripped
***@deb4g:~/fpc/fpc-3.0.0+dfsg#

Any idea?

Adrian

[John Paul Adrian Glaubitz]

Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.

Adrian

[John Paul Adrian Glaubitz]

Post by John Paul Adrian Glaubitz
Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.

From the build log:

as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o sparc/prt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o sparc/dllprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o sparc/cprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o sparc/gprt0.as

So, no options passed at all.

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.

I'm looking into it now. Stay tuned. I managed to reproduce your linker
problem already, at least. :)

Post by John Paul Adrian Glaubitz
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o sparc/prt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o sparc/dllprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o sparc/cprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o sparc/gprt0.as

Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.free

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.

I'm looking into it now. Stay tuned. I managed to reproduce your linker
problem already, at least. :)

Thanks. But the linker problem is just a result of the assembler not
playing nicely. The linker did nothing wrong ;-).

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o sparc/prt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o sparc/dllprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o sparc/cprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o sparc/gprt0.as

Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

But isn't the Makefile generated from fpcmake? :-O

Let me know if you need access to a porterbox.

Adrian

[Tomas Hajny]

On Mon, May 29, 2017 14:29, John Paul Adrian Glaubitz wrote:
.
.

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o

sparc/prt0.as

Post by John Paul Adrian Glaubitz
as -o

/root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o
sparc/dllprt0.as

Post by John Paul Adrian Glaubitz
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o

sparc/cprt0.as

Post by John Paul Adrian Glaubitz
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o

sparc/gprt0.as
Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

But isn't the Makefile generated from fpcmake? :-O

That doesn't make any difference in this case. This part would still need
to be changed in Makefile.fpc; your change affects assembly of files
generated by the compiler from Pascal sources, whereas these loaders are
hand-written in assembler and supplied as part of the RTL sources for the
particular platform.

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepasc

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz
Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.

I'm looking into it now. Stay tuned. I managed to reproduce your linker
problem already, at least. :)

Thanks. But the linker problem is just a result of the assembler not
playing nicely. The linker did nothing wrong ;-).

Right, I just meant I'm approaching the actual problem to fix. :)

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o sparc/prt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o sparc/dllprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o sparc/cprt0.as
as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o sparc/gprt0.as

Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

But isn't the Makefile generated from fpcmake? :-O

It is, but it's *pregenerated*, and committed to the SVN. The build
process doesn't generate any Makefiles, actually. (Lets not argue now it
is a nice practice or not, it is what it is...) To fix this, one has to
regenerate them. But it's complicated. ;) I'm not sure if you actually has
to fix inside fpcmake or the submitted Makefile.fpc which fpcmake uses to
generate the actual Makefile. But by the time I get there I'll figure it
out. One problem at a time.

Post by John Paul Adrian Glaubitz
Let me know if you need access to a porterbox.

Probably. If I get to something, I'll drop you a pubkey.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listi

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
But isn't the Makefile generated from fpcmake? :-O

It is, but it's *pregenerated*, and committed to the SVN. The build
process doesn't generate any Makefiles, actually. (Lets not argue now it
is a nice practice or not, it is what it is...) To fix this, one has to
regenerate them. But it's complicated. ;) I'm not sure if you actually has
to fix inside fpcmake or the submitted Makefile.fpc which fpcmake uses to
generate the actual Makefile. But by the time I get there I'll figure it
out. One problem at a time.

Actually, the Debian package explicitly regenerates all Makefiles and
I assume the main reason being to make sure they are up-to-date.

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
Let me know if you need access to a porterbox.

Probably. If I get to something, I'll drop you a pubkey.

Great, thanks.

[Tomas Hajny]

On Mon, May 29, 2017 14:35, Karoly Balogh (Charlie/SGR) wrote:
.
.

Post by Karoly Balogh (Charlie/SGR)
It is, but it's *pregenerated*, and committed to the SVN. The build
process doesn't generate any Makefiles, actually. (Lets not argue now it
is a nice practice or not, it is what it is...) To fix this, one has to
regenerate them. But it's complicated. ;) I'm not sure if you actually has
to fix inside fpcmake or the submitted Makefile.fpc which fpcmake uses to
generate the actual Makefile. But by the time I get there I'll figure it
out. One problem at a time.

It shouldn't be that difficult in this case - have a look
fpcsrc/rtl/linux/Makefile.fpc. Look at lines 147-153 (mips) and modify
lines 162-166 (sparc) similarly (obviously, not all options used for mips
are relevant for sparc, but the logic should be similar). Once done, call
'fpcmake -Tall' in that directory.

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Tomas Hajny

Post by Karoly Balogh (Charlie/SGR)
It is, but it's *pregenerated*, and committed to the SVN. The build
process doesn't generate any Makefiles, actually. (Lets not argue now it
is a nice practice or not, it is what it is...) To fix this, one has to
regenerate them. But it's complicated. ;) I'm not sure if you actually has
to fix inside fpcmake or the submitted Makefile.fpc which fpcmake uses to
generate the actual Makefile. But by the time I get there I'll figure it
out. One problem at a time.

It shouldn't be that difficult in this case - have a look
fpcsrc/rtl/linux/Makefile.fpc. Look at lines 147-153 (mips) and modify
lines 162-166 (sparc) similarly (obviously, not all options used for mips
are relevant for sparc, but the logic should be similar). Once done, call
'fpcmake -Tall' in that directory.

Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
added -32 into sparc/cpugas.pas file as I said, and from then on I started
getting 32 bit object files, and after fixing the Makefile, I got a 32bit
FP executable, crosscompiled. Maybe something on the buildbox will reveal,
why it doesn't work there.

I'm crosscompiling from Darwin, using binutils 2.27, which I built as
sparc64-linux-gnu target.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-b

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)
Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
added -32 into sparc/cpugas.pas file as I said, and from then on I started
getting 32 bit object files, and after fixing the Makefile, I got a 32bit
FP executable, crosscompiled. Maybe something on the buildbox will reveal,
why it doesn't work there.

Nope. Still doesn't work here. Maybe my brain is just messing things
up in today's heat here in Berlin :O.

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Indeed, this worked. Also, not sure what Adrian was doing wrong, but I
added -32 into sparc/cpugas.pas file as I said, and from then on I started
getting 32 bit object files, and after fixing the Makefile, I got a 32bit
FP executable, crosscompiled. Maybe something on the buildbox will reveal,
why it doesn't work there.

Nope. Still doesn't work here. Maybe my brain is just messing things
up in today's heat here in Berlin :O.

I'm also sitting in Berlin, so we're having different delusions from the
heat then... :) BTW, I sent you a pubkey.

It's easy to test how the assembler behaves, using those standalone .as
files. So "sparc64-linux-gnu-as -Av9 -32 prt0.as -o prt0.o" should result
in a 32 bit object. If that doesn't work, nothing will.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-de

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)
I'm also sitting in Berlin, so we're having different delusions from the
heat then... :) BTW, I sent you a pubkey.

But I'm in the south-west of Berlin. Much hotter here :D.

I'll create you an account in a minute.

Post by Karoly Balogh (Charlie/SGR)
It's easy to test how the assembler behaves, using those standalone .as
files. So "sparc64-linux-gnu-as -Av9 -32 prt0.as -o prt0.o" should result
in a 32 bit object. If that doesn't work, nothing will.

OK, good idea for testing.

In the end, I want to build the Debian package. So, the patches have
to apply against that version.

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz
In the end, I want to build the Debian package. So, the patches have
to apply against that version.

Well. I applied a 1 line patch against rtl/linux/Makefile.fpc, to append
-32 when it builds the startup code, regenerated the Makefile using
fpcmake -Tall, then started a the build like this in ~/fpc/trunk/:

make all OPT="-ao-32"

Obviously, the startup compiler doesn't have the -32 fix, so this is why
it failed for you, but this option inject this option externally.

Then the build initial phase where it rebuilds a new compiler, and starts
to use it succeeds. Which is the good news! And then it went through the
point where it wants to build fpmake natively with the new compiler. Where
it fails with:

/home/charlie/fpc/trunk/compiler/ppcsparc fpmake.pp
-Fu/home/charlie/fpc/trunk/packages/fpmkunit/units_bs/sparc-linux
-Fu/home/charlie/fpc/trunk/rtl/units/sparc-linux -ao-32
Free Pascal Compiler version 3.1.1 [2017/05/29] for sparc
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Linux for SPARC
Compiling fpmake.pp
fpmake.pp(16,3) Note: Local variable "T" is assigned but never used
Assembling fpmake
Linking fpmake
fpmake.pp(49) Warning: "crti.o" not found, this will probably cause a
linking failure
fpmake.pp(49) Warning: "crtbegin.o" not found, this will probably cause a
linking failure
fpmake.pp(49) Warning: "crtend.o" not found, this will probably cause a
linking failure
fpmake.pp(49) Warning: "crtn.o" not found, this will probably cause a
linking failure
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lc
fpmake.pp(49) Error: Error while linking
fpmake.pp(49) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Makefile:1712: recipe for target 'fpmake' failed

Which is because the buildbox doesn't have these 32bit libraries
installed, so FPC obviously cannot link against them. This is because the
very limited multiarch you mentioned before I guess. Now, FPC doesn't need
Libc on linux for its own functionality, but it needs it for FPmake.

Now, FPMake is not to be mixed with FPCMake, the former is a package build
system which is used for the Packages and the IDE. It needs
libc/libpthreads for the parallel builds... (Multithreaded applications
link against libc/libpthreads with FPC under Linux, single threaded
normally do not.)

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)
Obviously, the startup compiler doesn't have the -32 fix, so this is why
it failed for you, but this option inject this option externally.

Ok, I'm an idiot. I completely forgot about fixing the stage0 compiler ...

Post by Karoly Balogh (Charlie/SGR)
Then the build initial phase where it rebuilds a new compiler, and starts
to use it succeeds. Which is the good news! And then it went through the
point where it wants to build fpmake natively with the new compiler. Where
(...)
Which is because the buildbox doesn't have these 32bit libraries
installed, so FPC obviously cannot link against them. This is because the
very limited multiarch you mentioned before I guess. Now, FPC doesn't need
Libc on linux for its own functionality, but it needs it for FPmake.

We can easily install a 32-bit C library. It's one of the things that
actually get build, even on 64-bit systems.

I'll just install that, second.

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Which is because the buildbox doesn't have these 32bit libraries
installed, so FPC obviously cannot link against them. This is because the
very limited multiarch you mentioned before I guess. Now, FPC doesn't need
Libc on linux for its own functionality, but it needs it for FPmake.

We can easily install a 32-bit C library. It's one of the things that
actually get build, even on 64-bit systems.
I'll just install that, second.

Oh, ok. Nice. :) I'll wait then.

Charlie

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
I'll just install that, second.

Oh, ok. Nice. :) I'll wait then.

libc6-sparc was already installed:

***@deb4g:~# apt show libc6-sparc
Package: libc6-sparc
Version: 2.24-10
Priority: optional
Section: libs
Source: glibc
Maintainer: GNU Libc Maintainers <debian-***@lists.debian.org>
Installed-Size: 10.1 MB
Depends: libc6 (= 2.24-10)
Homepage: http://www.gnu.org/software/libc/libc.html
Download-Size: 2,380 kB
APT-Manual-Installed: yes
APT-Sources: http://ftp.ports.debian.org/debian-ports unstable/main sparc64 Packages
Description: GNU C Library: 32bit Shared libraries for SPARC
This package includes shared versions of the standard C library and the
standard math library, as well as many others. This is the 32bit version
of the library, meant for SPARC systems.

***@deb4g:~#

Make sure to pass -L/lib32 to the linker because that's where libc6-sparc
gets installed into:

***@deb4g:~# dpkg -L libc6-sparc |head
/.
/etc
/etc/ld.so.conf.d
/etc/ld.so.conf.d/zz_sparc-biarch-compat.conf
/lib
/lib32
/lib32/ld-2.24.so
/lib32/libBrokenLocale-2.24.so
/lib32/libSegFault.so
/lib32/libanl-2.24.so
***@deb4g:~#

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz
Make sure to pass -L/lib32 to the linker because that's where libc6-sparc
/.
/etc
/etc/ld.so.conf.d
/etc/ld.so.conf.d/zz_sparc-biarch-compat.conf
/lib
/lib32
/lib32/ld-2.24.so
/lib32/libBrokenLocale-2.24.so
/lib32/libSegFault.so
/lib32/libanl-2.24.so

Now, my knowledge on linking-against-libc thiings regarding FPC are a bit
rusty, but I'm quite positive we don't need the .so files there at linking
stage, but we need the accompanying .a files from the -dev package?

However, these also seem to be installed in /usr/lib32... So build running
now, lets see what happens.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http:/

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Karoly Balogh (Charlie/SGR)
However, these also seem to be installed in /usr/lib32... So build running
now, lets see what happens.

Different error: ... :/ I would gladly keep working on this, but I kinda
ran out of time for now, I can take a deeper look maybe tomorrow, or in
the coming weeks. Sharing this, so meanwhile maybe someone has an idea?

I'm sure i've seen this error before on other platforms, but I can't
remember the solution. Something with the linker scripts vs. startup
code vs. paths definitely.

Free Pascal Compiler version 3.1.1 [2017/05/29] for sparc
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Linux for SPARC
Compiling fpmake.pp
fpmake.pp(16,3) Note: Local variable "T" is assigned but never used
Assembling fpmake
Linking fpmake
fpmake.pp(49) Warning: "crti.o" not found, this will probably cause a
linking failure
fpmake.pp(49) Warning: "crtbegin.o" not found, this will probably cause a
linking failure
fpmake.pp(49) Warning: "crtend.o" not found, this will probably cause a
linking failure
fpmake.pp(49) Warning: "crtn.o" not found, this will probably cause a
linking failure
/home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function
`_start':
(.text+0x58): undefined reference to `_init'
/home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function
`_start':
(.text+0x5c): undefined reference to `_fini'
/home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function
`_start':
(.text+0x64): undefined reference to `_init'
/home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function
`_start':
(.text+0x68): undefined reference to `_fini'
fpmake.pp(49) Error: Error while linking
fpmake.pp(49) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/ma

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Karoly Balogh (Charlie/SGR)

Post by Karoly Balogh (Charlie/SGR)
However, these also seem to be installed in /usr/lib32... So build running
now, lets see what happens.

Different error: ... :/ I would gladly keep working on this, but I kinda
ran out of time for now, I can take a deeper look maybe tomorrow, or in
the coming weeks. Sharing this, so meanwhile maybe someone has an idea?
I'm sure i've seen this error before on other platforms, but I can't
remember the solution. Something with the linker scripts vs. startup
code vs. paths definitely.

Did a last attempt, and bingo. :)

make all OPTS="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"

Then everything builds, including the FP IDE, and all tools as expected.

Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for
SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe
it's also possible to just add ASTARGET=-32 into the make command line,
without patching the Makefile. But I did not try this.

Can you try if you can reproduce this?

Now, how to package this, or what to commit as fix in trunk/fixes branch,
is another question. :)

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)
Did a last attempt, and bingo. :)

Awesome \o/.

Post by Karoly Balogh (Charlie/SGR)
make all OPTS="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
Then everything builds, including the FP IDE, and all tools as expected.
Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for
SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe
it's also possible to just add ASTARGET=-32 into the make command line,
without patching the Makefile. But I did not try this.
Can you try if you can reproduce this?

Sure. Can you put the cross-compiled ppcsparc somewhere so I can find
and use it?

Post by Karoly Balogh (Charlie/SGR)
Now, how to package this, or what to commit as fix in trunk/fixes branch,
is another question. :)

Well, all the -32 options should definitely go into trunk. Upstream
doesn't support anything but 32 bits for SPARC anyway and after
looking at the rtl/linux/Makefile.fpc, you already do this for mips32.

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Can you try if you can reproduce this?

Sure. Can you put the cross-compiled ppcsparc somewhere so I can find
and use it?

You don't need one. :) See my other mail. Although I did crosscompile a
new bootstrap compiler, in the end I did not need it.

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Now, how to package this, or what to commit as fix in trunk/fixes branch,
is another question. :)

Well, all the -32 options should definitely go into trunk. Upstream
doesn't support anything but 32 bits for SPARC anyway and after
looking at the rtl/linux/Makefile.fpc, you already do this for mips32.

I tend to agree in both. I still want to have the opinion of someone in
the FPC team who feels more like a sparc-linux guy than me.

(That means if there will be no response in 1-2 days, I will go ahead with
the changes in trunk. :P)

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/

[Tomas Hajny]

Hi,

.
.

Post by Karoly Balogh (Charlie/SGR)

Post by John Paul Adrian Glaubitz
Well, all the -32 options should definitely go into trunk. Upstream
doesn't support anything but 32 bits for SPARC anyway and after
looking at the rtl/linux/Makefile.fpc, you already do this for mips32.

I tend to agree in both. I still want to have the opinion of someone in
the FPC team who feels more like a sparc-linux guy than me.
(That means if there will be no response in 1-2 days, I will go ahead with
the changes in trunk. :P)

Not that I'm the one to provide the answer, but I guess that it would be
useful to check, whether / since when the '-32' parameter is supported on
the 32-bit version of Sparc/Linux. If it hasn't already been supported (or
at least ignored ;-) ) for ages there, the minimum version supporting it
needs to be mentioned somewhere in the readme, etc., and also added to the
Wiki page User_changes_trunk, because the compiler would probably not work
for the older versions any longer after that change.

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fp

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Karoly Balogh (Charlie/SGR)
Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for
SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe
it's also possible to just add ASTARGET=-32 into the make command line,
without patching the Makefile. But I did not try this.
Can you try if you can reproduce this?

Err, sorry, there's a typo in the previous line I've sent. here's the
correct one. Also, ASTARGET= override seems to work, so you don't need to
patch the sources, you can fix it during build with options.

Like this:

make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"

This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
Debian SPARC64 box without patching anything. Now, if you want to patch
the compiler for this, or simply wire additional options to the package
supplied fpc.cfg with the right paths and options, that decision is not
mine to make. I'm not the Linux maintainer, and even less of a SPARC
maintainer. :)

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Karoly Balogh (Charlie/SGR)
make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
Debian SPARC64 box without patching anything.

Just for the record, the same command line can be used to build the
fixes_3_0 branch without any patching or Makefile-messing as well. I just
tried on that box, and it worked.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.f

[Tomas Hajny]

Post by Karoly Balogh (Charlie/SGR)
Hi,

Post by Karoly Balogh (Charlie/SGR)
make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
Debian SPARC64 box without patching anything.

Just for the record, the same command line can be used to build the
fixes_3_0 branch without any patching or Makefile-messing as well. I just
tried on that box, and it worked.

However, it should probably not be merged to fixes, because it may be a
breaking change for older Sparc/Linux versions (see my previous e-mail;
note that the situation with MIPS was probably different, because the
support of that CPU is much newer).

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal

[John Paul Adrian Glaubitz]

Post by Tomas Hajny
However, it should probably not be merged to fixes, because it may be a
breaking change for older Sparc/Linux versions (see my previous e-mail;
note that the situation with MIPS was probably different, because the
support of that CPU is much newer).

I am pretty sure that the "-32" option hasn't changed for aeons, so
there is nothing to break here. And, as I mentioned before, you are
already passing "-b elf32-sparc -m elf32_sparc" to ld, so adding "-32"
to the assembler would not hurt at all.

I can even ask one of Oracle's toolchain SPARC team members to confirm
my assessment. In fact, I will just do this now.

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by John Paul Adrian Glaubitz

Post by Tomas Hajny
However, it should probably not be merged to fixes, because it may be a
breaking change for older Sparc/Linux versions (see my previous e-mail;
note that the situation with MIPS was probably different, because the
support of that CPU is much newer).

I am pretty sure that the "-32" option hasn't changed for aeons, so
there is nothing to break here. And, as I mentioned before, you are
already passing "-b elf32-sparc -m elf32_sparc" to ld, so adding "-32"
to the assembler would not hurt at all.

From what I can see, binutils 2.9.1, released 1/5/1998 (19+ years ago)
already has it for SPARC (according to the man page). :) But binutils
2.8.1 from 20 years ago, still didn't. So it was added between those
versions. :)

I cannot confirm this now, but I'm willing to make a bet that our
generated assembly syntax already depends on newer binutils, for things
like named sections. Although I'm not sure these are enabled for SPARC in
their full glory.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/list

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)
From what I can see, binutils 2.9.1, released 1/5/1998 (19+ years ago)
already has it for SPARC (according to the man page). :) But binutils
2.8.1 from 20 years ago, still didn't. So it was added between those
versions. :)

Not surprising. SPARCv9 has been around since the mid-90ies.

Adrian

[John Paul Adrian Glaubitz]

Post by Karoly Balogh (Charlie/SGR)
Err, sorry, there's a typo in the previous line I've sent. here's the
correct one. Also, ASTARGET= override seems to work, so you don't need to
patch the sources, you can fix it during build with options.
make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
Debian SPARC64 box without patching anything.

Ok, that's a good start. Thank you!

Post by Karoly Balogh (Charlie/SGR)
Now, if you want to patch the compiler for this, or simply wire
additional options to the package supplied fpc.cfg with the right
paths and options, that decision is not mine to make. I'm not the
Linux maintainer, and even less of a SPARC maintainer. :)

I need to figure out where the package's own fpc.cfg resides. The
packaging is a bit confusing.

Adrian

[Tomas Hajny]

.
.

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Now, if you want to patch the compiler for this, or simply wire
additional options to the package supplied fpc.cfg with the right
paths and options, that decision is not mine to make. I'm not the
Linux maintainer, and even less of a SPARC maintainer. :)

I need to figure out where the package's own fpc.cfg resides. The
packaging is a bit confusing.

It's usually created on the fly during installation. See
fpcsrc/utils/fpcmkcfg/fpc.cft.

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.o

[Florian Klämpfl]

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
Err, sorry, there's a typo in the previous line I've sent. here's the
correct one. Also, ASTARGET= override seems to work, so you don't need to
patch the sources, you can fix it during build with options.
make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"
This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on the
Debian SPARC64 box without patching anything.

Ok, that's a good start. Thank you!

Post by Karoly Balogh (Charlie/SGR)
Now, if you want to patch the compiler for this, or simply wire
additional options to the package supplied fpc.cfg with the right
paths and options, that decision is not mine to make. I'm not the
Linux maintainer, and even less of a SPARC maintainer. :)

The -Fo and -Fl can go into t_linux.pas, adding -32 for the sparc assembler should be supported for
years, so it can go into compiler/sparc/cpugas.pas

Post by John Paul Adrian Glaubitz
I need to figure out where the package's own fpc.cfg resides. The
packaging is a bit confusing.
Adrian

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-deve

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Karoly Balogh (Charlie/SGR)
make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32"

So Adrian, I've got a question. Looking at fixing this in the right way,
the linker search paths at least.

What's the right directory to search for libs and objects in a multiarch
system? I can add /lib32;/usr/lib32, etc. to the default library search
path for FPC, but i find references online that's the "old" way, and the
new way should be /usr/lib/<archname>, like sparc64-linux-gnu, and
sparc-linux-gnu... However, this later is lacking on the buildbox, while
there is /lib32... Or are these complementary?

The library search paths seems a bit hardwired in t_linux.pas. I can add
something like /lib32;/usr/lib32;/usr/X11R6/lib32 for all 32bit platforms,
but not sure if that makes sense. I also don't know how "standard" is this
among distros.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bi

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Karoly Balogh (Charlie/SGR)
Which is because the buildbox doesn't have these 32bit libraries
installed, so FPC obviously cannot link against them. This is because the
very limited multiarch you mentioned before I guess. Now, FPC doesn't need
Libc on linux for its own functionality, but it needs it for FPmake.
Now, FPMake is not to be mixed with FPCMake, the former is a package build
system which is used for the Packages and the IDE. It needs
libc/libpthreads for the parallel builds... (Multithreaded applications
link against libc/libpthreads with FPC under Linux, single threaded
normally do not.)

So the bottom line is in clear words: FPC will need at least the
fundamental libs (libc, pthreads, libdl) installed on the buildbox in
32bit versions (multiarch), or the rest of the build sinply won't work,
and cannot be made to work easily.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.f

[Tomas Hajny]

Post by John Paul Adrian Glaubitz
Even passing "-Av8plus" does not help. So, the options from
compiler/sparc/cpugas.pas are definitely not passed to the assembler.

Are you sure that you rebuilt the compiler completely after your change
and that you invoked the right (newly built) version while testing the
performed change? Do you call 'fpc', or 'ppcsparc' while testing it (the
former may result in calling a previously installed version of ppcsparc
rather than the newly built one)?

Apart from trying various -v levels (at least -vl comes to mind to see the
compiler build date, -vt showing the used paths including the one of the
compiler, or even -va showing all the details) to check what's going on,
you can see the passed options if calling the compiler with parameter -s.

Tomas


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/

[John Paul Adrian Glaubitz]

Post by Tomas Hajny
Are you sure that you rebuilt the compiler completely after your change
and that you invoked the right (newly built) version while testing the
performed change? Do you call 'fpc', or 'ppcsparc' while testing it (the
former may result in calling a previously installed version of ppcsparc
rather than the newly built one)?

Yes, I always did a full clean of the source repository and restart
the build from scratch.

Post by Tomas Hajny
Apart from trying various -v levels (at least -vl comes to mind to see the
compiler build date, -vt showing the used paths including the one of the
compiler, or even -va showing all the details) to check what's going on,
you can see the passed options if calling the compiler with parameter -s.

I can try -va. But as Charlie already indicated, the wrong assembler
invocations probably come from the Makefiles, not ppcsparc itself.

Adrian

[Florian Klämpfl]

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
And/or completely unprepared for 64bit in any way.

I actually don't think there would be much work necessary. fpc already
supports SPARCv9 which is actually by default a 64-bit architecture
(also known as UltraSPARC).

Well, fpc has a SPARCv9 switch, but it does little to none and it was only supposed to enable
SPARCv9 instructions in 32 bit only mode. SPARC64 is another story: it needs some more work, it is
basically a new target for the compiler though a lot of code can be reused from SPARC32. I am also
interested on working on a SPARC64. Actually, several weeks ago, I literally un-dusted my Ultra 5
which sat in the attic for years. But I did not start to work on the port yet, but I still plan to
do so, so at a certain point access to a fast SPARC64 machine would be nice indeed.

Post by John Paul Adrian Glaubitz
I also don't think it will be that hard given the fact that the
important part, a code generator for SPARCv9, is already in place.
I can also provide a machine that could be used for running the
testsuite on Linux/sparc64. We already provide such a machine for the
QEMU upstream developers to test on sparc64.
Adrian

_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-deve

[John Paul Adrian Glaubitz]

Post by Florian Klämpfl
Well, fpc has a SPARCv9 switch, but it does little to none and it was only supposed to enable
SPARCv9 instructions in 32 bit only mode. SPARC64 is another story: it needs some more work, it is
basically a new target for the compiler though a lot of code can be reused from SPARC32.

I see, thanks for the explanation.

Post by Florian Klämpfl
I am also interested on working on a SPARC64. Actually, several weeks ago, I literally un-dusted my Ultra 5
which sat in the attic for years. But I did not start to work on the port yet, but I still plan to
https://lists.debian.org/debian-sparc/2016/06/msg00126.html

This explains how. It's still a bit bumpy, but it should work.

Post by Florian Klämpfl
do so, so at a certain point access to a fast SPARC64 machine would be nice indeed.

We have a SPARC-T5 with lots of RAM and even more compute power. The machine is much
faster than even most x86_64 machines ;). Just drop me a private mail with your
SSH public key when you want to have an account.

Adrian

[John Paul Adrian Glaubitz]

The important thing to know about the linker on 32-bit Solaris is the -Xn
option to force the native one to be used. Apart from that more info is
needed before anybody here can comment.

Looking at compiler/system/t_linux.pas, fpc does enforce 32-bit mode
for the linker. It seems to be missing for the compiler/assembler
though such that 64-bit code is generated by default on sparc64.

32-bit 3.0.2 builds without problems for both Linux and Solaris, and by and
large works including the Lazarus IDE.

Yes, it works on sparc64. But trying to build anything results in
linker errors because the generated object files are 64 bits.

My recollection is that the SPARC64 code generator is immature, hopefully
Jonas will comment on that.

So, what does it generate by default? SPARCv7 or SPARCv8? Both are
ancient and all Linux distributions have been on SPARCv9 for ages,
just not with 64-bit pointers.

Adrian, I've put very little time into the SPARC 64-bit Debian port, and
despite tracking the mailing list I'm a little unclear how complete it is
and- in particular- how easily it installs. Does it support multiarch to
allow 32-bit binaries to run seamlessly?

There is limited multi-arch support because the buildds are currently
not building any 32-bit binaries and hence we don't have most shared
libraries compiled as 32-bit SPARC. However, 32-bit support itself is
in place and working. So, in the worst case, you'd just have to build
any libraries you need as 32-bit SPARC.

On a sidenote: After patching compiler/systems/t_linux.pas to link
with 64-bit linker flags, the build succeeded. However, the resulting
binaries crashes with a bus error, i.e. unaligned access. It may just
be a matter of a small patch to fix this issue though.

Adrian

[Karoly Balogh (Charlie/SGR)]

Hi,

My recollection is that the SPARC64 code generator is immature,
hopefully Jonas will comment on that.

Not sure what "immature" means, granted, I don't know anything about
SPARC, but from what I see, FPC definitely handles SPARC as a 32bit only
architecture now. All the definitions in fpcdefs.inc hardwires CPU
settings as 32bit, it doesn't seem to know about a 64bit ALU,
sparc/cpubase has only sizes defined as 32bit, etc.

And I can't see a separate SVN branch for 64bit either. So I'd say it's
simply "not there"?

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fp

[Marco van de Voort]

Post by Karoly Balogh (Charlie/SGR)
Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

(neither are they for *BSD since those use weak symbols)
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cg

[Karoly Balogh (Charlie/SGR)]

Hi,

Post by Marco van de Voort

Post by Karoly Balogh (Charlie/SGR)
Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

(neither are they for *BSD since those use weak symbols)

Is it still required? Darwin does all kinds of weak linking too, and it
has a Pascal written startup code if I'm correct.

Charlie
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-d

[Jonas Maebe]

Post by Karoly Balogh (Charlie/SGR)
Is it still required? Darwin does all kinds of weak linking too, and it
has a Pascal written startup code if I'm correct.

We use the libc startup code on Darwin. FPC only supports referencing
external weak symbols. It does not (yet) support defining weak symbols.


Jonas
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepasca

[Marco van de Voort]

Post by John Paul Adrian Glaubitz

Post by Karoly Balogh (Charlie/SGR)
generate the actual Makefile. But by the time I get there I'll figure it
out. One problem at a time.

Actually, the Debian package explicitly regenerates all Makefiles and
I assume the main reason being to make sure they are up-to-date.

Many package/ports systems do this to effectuate (possible) distro patches
to the fpc files. Release sources/branches however always have been updated
before release.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listi

[Marco van de Voort]

Post by Karoly Balogh (Charlie/SGR)

Post by Marco van de Voort

Post by Karoly Balogh (Charlie/SGR)
Err, those are invoked directly from the Makefile, not invoked from inside
FPC. But you're right, that will be also a problem... Some platforms still
use asm-written startup stubs in FPC. Not all of them tho'. I think these
days these startup codes could be written in Pascal anyway, but for Sparc
they're not.

(neither are they for *BSD since those use weak symbols)

Is it still required? Darwin does all kinds of weak linking too, and it
has a Pascal written startup code if I'm correct.

I don't know much about how linking on Darwin works, but afaik it has a
different object format ?

I tried a long time ago (2010ish), and then got stuck. Afaik the remains are
still in the i386/ directory.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-dev