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

Hi,

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/

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

Hi!

Aha.

Which might suggest that the trunk could be broken at this point. :(

The build actually succeeds with the modifications I made.

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.

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

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

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

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.

> 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 cantake a look. In fact, maybe even a full 64bit SPARC port shouldn't be thathard (famous last words...), but at least a few weeks of work for sure forsomeone who knows the compiler internals.

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

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

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?

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

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.

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

Adrian

Mark Morgan Lloyd wrote

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

Hi,

John Paul Adrian Glaubitz wrote

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

Good idea, I'll try that.

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

Hi,

Mark Morgan Lloyd wrote

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

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:

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

Any idea?

Adrian

I /thought/ that there used to be something, and that I'd discussed it briefly some while ago with Jonas. After all, we're probably the last people to still have a (small) number of desktop systems, and it seems to be me who's caused most of the hassle about the architecture over the years :-)

I notice that Jonas commented recently
https://forum.lazarus.freepascal.org/index.php?topic=36272.0

John Paul Adrian Glaubitz wrote

I tried adding "-32" like this:

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

Adrian

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
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer -
`. `' Freie Universitaet Berlin -
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

Hi,

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

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

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

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

Let me know if you need access to a porterbox.

Adrian

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

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

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

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

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

Hi,

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

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.

Let me know if you need access to a porterbox.

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

Charlie

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

> Let me know if you need access to a porterbox. Probably. If I get to something, I'll drop you a pubkey.

Great, thanks.

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

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

Hi,

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

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

Adrian

Hi,

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

Karoly Balogh wrote

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.

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.

Hi,

John Paul Adrian Glaubitz wrote

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

Karoly Balogh wrote

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

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

Hi,

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

Hi,

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

Charlie

Karoly Balogh wrote

> I'll just install that, second. Oh, ok. Nice. :) I'll wait then.

libc6-sparc was already installed:

apt show libc6-sparc
Package: libc6-sparc
Version: 2.24-10
Priority: optional
Section: libs
Source: glibc
Maintainer: GNU Libc Maintainers
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.

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

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

Adrian

Hi,

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

Hi,

Karoly Balogh wrote

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

Hi,

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

Karoly Balogh wrote

Did a last attempt, and bingo. :)

Awesome \o/.

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

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

Hi,

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

Hi,

John Paul Adrian Glaubitz wrote

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

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

Hi,

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

Karoly Balogh wrote

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

Hi,

.
.

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

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

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

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

Tomas Hajny wrote

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 can even ask one of Oracle's toolchain SPARC team members to confirm my assessment. In fact, I will just do this now.

Adrian

John Paul Adrian Glaubitz wrote

On Mon, May 29, 2017 at 05:11:52PM +0200, Karoly Balogh (Charlie/SGR) wrote:

.
.

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

Tomas

Hi,

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

Karoly Balogh wrote

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

Hi,

Karoly Balogh wrote

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

I'm happy enough to test on the OSes etc. that I've got set up here.

Is it /just/ that command line? Is this going via Mantis?

Whatever, good work everybody. It's a public holiday in the UK- it is in Berlin as well or is the flurry of work just a coincidence?

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

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.

Florian Klämpfl wrote

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.

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

In case you want to install a current release of Debian/sparc64:

https://lists.debian.org/debian-sparc/2016/06/msg00126.html

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

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

In our previous episode, Karoly Balogh (Charlie/SGR) said:

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

In our previous episode, John Paul Adrian Glaubitz said:

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.

Hi,

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

In our previous episode, Karoly Balogh (Charlie/SGR) said:

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.

Karoly Balogh wrote

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