1. Forum
  2. Usenet
  3. LINUX.DEBIAN.PORTS.68K

  • Debugging FPC build issue on m68k

    From Abou Al Montacir@21:1/5 to All on Tue Aug 4 17:50:02 2020
    --=-+kgqRQmcPde4BA8TyMIl
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    Dear Teams,

    I started looking at the m68k build issue, but the buildd logs are not enough to
    understand what happens.
    I tried to find a m68k machine on porter boxes but failed to find any.
    Also building a qemu image does not seem as straight forward as I expected, so I'd like to know if anybody can help providing access to a machine or a qemu image that I can download.
    Of course, any help to debug this issue is more than welcome.
    --
    Cheers,
    Abou Al Montacir


    --=-+kgqRQmcPde4BA8TyMIl
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html dir="ltr"><head></head><body style="text-align:left; direction:ltr;" bgcolor="#ffffff" text="#2e3436" link="#1b6acb" vlink="#2e3436"><div>Dear Teams,</div><div><br></div><div>I started looking at the m68k build issue, but <a href="https://buildd.
    debian.org/status/fetch.php?pkg=fpc&amp;arch=m68k&amp;ver=3.2.0%2Bdfsg-4&amp;stamp=1596546085&amp;raw=0">the buildd logs</a> are not enough to understand what happens.</div><div>I tried to find a m68k machine on porter boxes but failed to find any.</div><
    Also building a qemu image does not seem as straight forward as I expected, so I'd like to know if anybody can help providing access to a machine or a qemu image that I can download.</div><div>Of course, any help to debug this issue is more than
    welcome.</div><div><span><pre><pre>-- <br></pre>Cheers,
    Abou Al Montacir
    </pre></span></div></body></html>
  • From Carsten Strotmann@21:1/5 to Abou Al Montacir on Tue Aug 4 21:00:01 2020
    Hello Abou Al Montacir,

    Abou Al Montacir <abou.almontacir@sfr.fr> writes:

    Dear Teams,

    I started looking at the m68k build issue, but the buildd logs
    are not enough to
    understand what happens.
    I tried to find a m68k machine on porter boxes but failed to
    find any.
    Also building a qemu image does not seem as straight forward as
    I expected, so
    I'd like to know if anybody can help providing access to a
    machine or a qemu
    image that I can download.
    Of course, any help to debug this issue is more than welcome.

    I can possibly setup a machine in the Internet with qemu emulation
    for
    you, and I can also send you a download link for my Debian m68k
    directory and instructions on how to setup a emulated system from
    the
    image download.

    I can probably have that ready by Thursday this week. Let me know
    if you
    would like to try that, or if you got access to a machine
    somewhere
    else.

    Greetings

    Carsten

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Abou Al Montacir on Tue Aug 4 22:30:01 2020
    Hi Abou!

    On 8/4/20 5:33 PM, Abou Al Montacir wrote:
    I started looking at the m68k build issue, but the buildd logs are not enough to
    understand what happens.
    I tried to find a m68k machine on porter boxes but failed to find any.
    Also building a qemu image does not seem as straight forward as I expected, so
    I'd like to know if anybody can help providing access to a machine or a qemu image that I can download.
    Of course, any help to debug this issue is more than welcome.

    I have already reported this issue upstream [1], but so far I have not received any feedback. Charlie (CC'ed) from upstream who is mainly responsible for the m68k backend as far as I know said he would look into it.

    If you want to set up a Debian/m68k VM yourself, please have a look at [2].

    Thanks,
    Adrian

    [1] https://bugs.freepascal.org/view.php?id=37250
    [2] https://wiki.debian.org/M68k/QemuSystemM68k

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Abou Al Montacir@21:1/5 to John Paul Adrian Glaubitz on Tue Aug 4 23:40:02 2020
    --=-2d7VMvppU0pSeVBG7yXo
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    Hi Adrian,
    On Tue, 2020-08-04 at 22:26 +0200, John Paul Adrian Glaubitz wrote:
    Hi Abou!
    On 8/4/20 5:33 PM, Abou Al Montacir wrote:
    I started looking at the m68k build issue, but the buildd logs are not enough tounderstand what happens.I tried to find a m68k machine on porter boxes but failed to find any.Also building a qemu image does not seem as straight forward as I expected, soI'd like to know if anybody can help providing access to a machine or a qemuimage that I can download.Of course, any help to debug this issue is more than welcome.

    I have already reported this issue upstream [1], but so far I have not receivedany feedback. Charlie (CC'ed) from upstream who is mainly responsible for them68k backend as far as I know said he would look into it.
    It looks that Pierre already answered there and is waiting for feedback.
    If you want to set up a Debian/m68k VM yourself, please have a look at [2].
    That looks too complicated for me.
    I don't feel having the energy to build my qemu and install my image.

    I've got a qcow2 image from Laurent (many thanks)
    I'm going to have a trial with qemu-system-misc (1:3.1+dfsg-8+deb10u7)
    --
    Cheers,
    Abou Al Montacir



    --=-2d7VMvppU0pSeVBG7yXo
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html dir="ltr"><head></head><body style="text-align:left; direction:ltr;" bgcolor="#ffffff" text="#2e3436" link="#1b6acb" vlink="#2e3436"><div>Hi Adrian,</div><div><span><pre><pre><br></pre></pre></span></div><div>On Tue, 2020-08-04 at 22:26 +0200, John
    Paul Adrian Glaubitz wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Hi Abou!</pre><pre><br></pre><pre>On 8/4/20 5:33 PM, Abou Al Montacir wrote:</pre><blockquote type="cite" style="
    margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>I started looking at the m68k build issue, but the buildd logs are not enough to</pre><pre>understand what happens.</pre><pre>I tried to find a m68k machine on porter boxes but
    failed to find any.</pre><pre>Also building a qemu image does not seem as straight forward as I expected, so</pr
  • From Karoly Balogh (Charlie/SGR)@21:1/5 to John Paul Adrian Glaubitz on Wed Aug 12 11:40:02 2020
    Hi,

    On Tue, 4 Aug 2020, John Paul Adrian Glaubitz wrote:

    On 8/4/20 5:33 PM, Abou Al Montacir wrote:

    I started looking at the m68k build issue, but the buildd logs are not enough to understand what happens. I tried to find a m68k machine on
    porter boxes but failed to find any. Also building a qemu image does
    not seem as straight forward as I expected, so I'd like to know if
    anybody can help providing access to a machine or a qemu image that I
    can download. Of course, any help to debug this issue is more than
    welcome.

    I have already reported this issue upstream [1], but so far I have not received any feedback. Charlie (CC'ed) from upstream who is mainly responsible for the m68k backend as far as I know said he would look
    into it.

    If you want to set up a Debian/m68k VM yourself, please have a look at [2].

    Sorry for the delayed response, yes, we in upstream are willing to fix the issue, although we run regular tests with QEMU, and those are looking
    good. So not sure what could cause that build problem, but we're also
    mostly doing cross-builds with m68k, not native builds.

    I know I promised to look into this, but never really had time in the last
    few weeks, sorry about it. It turned out, our SVN trunk was broken for Linux-m68k, so I fixed that meanwhile, but FPC 3.2.0 was forked earlier to
    that breakage, so if there's an issue it must be different. I'll get
    there, meanwhile but of course any input is welcome.

    Charlie

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Abou Al Montacir@21:1/5 to All on Thu Aug 20 10:00:02 2020
    --=-7J7N+eiCOeqSr+SPkp3y
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    Hi Charlie,

    On Wed, 2020-08-12 at 11:38 +0200, Karoly Balogh (Charlie/SGR) wrote:
    Sorry for the delayed response, yes, we in upstream are willing to fix theissue, although we run regular tests with QEMU, and those are lookinggood. So not sure what could cause that build problem, but we're alsomostly doing cross-builds with m68k, not native builds.
    I know I promised to look into this, but never really had time in the lastfew weeks, sorry about it. It turned out, our SVN trunk was broken forLinux-m68k, so I fixed that meanwhile, but FPC 3.2.0 was forked earlier tothat breakage, so if there's an issue it must be different. I'll getthere, meanwhile but of course any input is welcome.
    I looked deeper in the issue and it seems that it may be a bug in the initial compiler /usr/bin/ppc68k which is used to bootstrap the cycle.
    This compiler is of version 3.0.4+dfsg-23.

    So a possible way to overcome this is to perform a binary upload to m68k. However I was not able to generate packages by cross compilation.
    --
    Cheers,
    Abou Al Montacir

    --=-7J7N+eiCOeqSr+SPkp3y
    Content-Type: text/html; charset="utf-8"
    Content-Transfer-Encoding: quoted-printable

    <html dir="ltr"><head></head><body style="text-align:left; direction:ltr;" bgcolor="#ffffff" text="#2e3436" link="#1b6acb" vlink="#2e3436"><div>Hi Charlie,</div><div><br></div><div>On Wed, 2020-08-12 at 11:38 +0200, Karoly Balogh (Charlie/SGR) wrote:</
    <blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>Sorry for the delayed response, yes, we in upstream are willing to fix the</pre><pre>issue, although we run regular tests with QEMU,
    and those are looking</pre><pre>good. So not sure what could cause that build problem, but we're also</pre><pre>mostly doing cross-builds with m68k, not native builds.</pre><pre><br></pre><pre>I know I promised to look into this, but never really had
    time in the last</pre><pre>few weeks, sorry about it. It turned out, our SVN trunk was broken for</pre><pre>Lin
  • From Karoly Balogh (Charlie/SGR)@21:1/5 to Abou Al Montacir on Thu Aug 20 12:30:01 2020
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    Hi,

    On Thu, 20 Aug 2020, Abou Al Montacir wrote:

    It turned out, our SVN trunk was broken for Linux-m68k, so I fixed that
    meanwhile, but FPC 3.2.0 was forked earlier to that breakage, so if
    there's an issue it must be different. I'll get there, meanwhile but of
    course any input is welcome.

    I looked deeper in the issue and it seems that it may be a bug in the
    initial compiler /usr/bin/ppc68k which is used to bootstrap the cycle.
    This compiler is of version 3.0.4+dfsg-23.

    Thanks for looking into this!

    Yeah, 3.0.4 is a very early version for m68k (after the m68k backend got revived), and the 3.0.4 was maybe the first ever version which really
    worked on Linux-m68k. So I was actually kinda surprised it even worked to
    that level, so it could be included in Debian... :) I would avoid fighting
    with that if possible.

    So a possible way to overcome this is to perform a binary upload to
    m68k. However I was not able to generate packages by cross compilation.

    I cross-built a recent 3.2.1 compiler from our fixes_3_2 branch (this will
    be released as 3.2.2, eventually), I uploaded it here:

    https://coderetro.net/temp/linux-m68k/

    Can you try bootstrapping with this compiler binary? At least from FPC's perspective, you shouldn't need anything else, to initiate a cross build
    than a bootstrap compiler binary, and GNU binutils and make. Not sure if
    Debian needs anything else.

    If this also crashes, then I have to dig deeper to identify the problem, because 3.2.x will be with us for a while, and I'd like it to be built for Debian-m68k.

    Cheers,
    --
    Charlie

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Karoly Balogh (Charlie/SGR)@21:1/5 to John Paul Adrian Glaubitz on Thu Aug 20 16:10:02 2020
    Hi,

    On Thu, 20 Aug 2020, John Paul Adrian Glaubitz wrote:

    I cross-built a recent 3.2.1 compiler from our fixes_3_2 branch (this will be released as 3.2.2, eventually), I uploaded it here:

    https://coderetro.net/temp/linux-m68k/

    Can you try bootstrapping with this compiler binary? At least from FPC's perspective, you shouldn't need anything else, to initiate a cross build than a bootstrap compiler binary, and GNU binutils and make. Not sure if Debian needs anything else.

    If this also crashes, then I have to dig deeper to identify the problem, because 3.2.x will be with us for a while, and I'd like it to be built for Debian-m68k.

    It still fails with:

    numlib/units/m68k-linux/spe.s: Assembler messages: numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point number
    spe.pas(1793) Error: Error while assembling exitcode 1
    spe.pas(1793) Fatal: There were 2 errors compiling module, stopping
    Fatal: Compilation aborted

    Can you send me that spe.s file which fails to compile? Also, which
    version of binutils is used? As this error comes from binutils (as), and
    not FPC itself, of course it could be that the generated assembly is
    broken at that line. I have a local build of (cross-)binutils 2.27, which
    I was using for testing. Maybe I should try with a newer one.

    I used your binary and the source tarball for FPC 3.2.0.

    I do have a build of that unit locally, and it builds without an issue, although admittedly, it's a cross build.

    Charlie

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to All on Thu Aug 20 15:50:01 2020
    On 8/20/20 12:20 PM, Karoly Balogh (Charlie/SGR) wrote:
    I cross-built a recent 3.2.1 compiler from our fixes_3_2 branch (this will
    be released as 3.2.2, eventually), I uploaded it here:

    https://coderetro.net/temp/linux-m68k/

    Can you try bootstrapping with this compiler binary? At least from FPC's perspective, you shouldn't need anything else, to initiate a cross build
    than a bootstrap compiler binary, and GNU binutils and make. Not sure if Debian needs anything else.

    If this also crashes, then I have to dig deeper to identify the problem, because 3.2.x will be with us for a while, and I'd like it to be built for Debian-m68k.

    It still fails with:

    numlib/units/m68k-linux/spe.s: Assembler messages: numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point number spe.pas(1793) Error: Error while assembling exitcode 1
    spe.pas(1793) Fatal: There were 2 errors compiling module, stopping
    Fatal: Compilation aborted

    The installer encountered the following error:
    Compilation of "BuildUnit_numlib.pp" failed
    make[2]: *** [Makefile:1729: smart] Error 1
    make[2]: Leaving directory '/root/src/fpc-3.2.0/packages'
    make[1]: *** [Makefile:2681: packages_smart] Error 2
    make[1]: Leaving directory '/root/src/fpc-3.2.0'
    make: *** [Makefile:2836: build-stamp.m68k-linux] Error 2

    I used your binary and the source tarball for FPC 3.2.0.

    Adrian

    --
    .''`. John Paul Adrian Glaubitz
    : :' : Debian Developer - glaubitz@debian.org
    `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
    `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Karoly Balogh (Charlie/SGR)@21:1/5 to John Paul Adrian Glaubitz on Fri Aug 21 05:30:01 2020
    Hi,

    On Thu, 20 Aug 2020, John Paul Adrian Glaubitz wrote:

    If this also crashes, then I have to dig deeper to identify the problem, >>> because 3.2.x will be with us for a while, and I'd like it to be built for
    Debian-m68k.

    It still fails with:

    numlib/units/m68k-linux/spe.s: Assembler messages:
    numlib/units/m68k-linux/spe.s:1751: Error: cannot create floating-point number
    spe.pas(1793) Error: Error while assembling exitcode 1
    spe.pas(1793) Fatal: There were 2 errors compiling module, stopping
    Fatal: Compilation aborted

    Can you send me that spe.s file which fails to compile?

    See attached.

    Ok, so the generated assembly is indeed wrong, but it's different to the cross-compiled assembly. What happens is in the optimizer the compiler
    tries to determine the lowest possible precision of a floating point
    constant, and this seems to go badly wrong in this case, and the compiler figures it can do a single precision floating point load for a double
    precision inline constant. And the assembler complains about that.

    However, I verified on real hardware (68060), I cannot reproduce this at
    least with the 3.2.0 Amiga native compiler, neither for native Amiga code,
    nor when crossbuilding for Linux. Then the generated assembly is always correct. I also verified if the native compiler contains the correct code sequence (by disassembling its binary) for that opimization, and the
    answer is yes.

    I really need to put my real hardware Linux-m68k setup together again, to
    be 100% sure this is not an FPC issue, but at this point I think it isn't.

    What is the build host? QEMU? If yes, which version? I tested a slightly
    older QEMU (3.1, as bundled with Raspbian), and its floating point support seems quite badly broken. Even trivial code which uses the FPU seems to
    fail. Like, printing the value of "Pi" seems to show '4.0' ... :) Like
    it's permanently stuck in round up mode, but fiddling with FPCR values
    don't seem to change anything. Same code works on real hardware and in
    UAE.

    BTW, FPU problems didn't occur in Free Pascal 3.0.4 because that could not
    use FPU at all, so this is not a regression. FPU support was new in 3.2.0
    for m68k. You can switch to software floating point support by passing OPT="-CfSOFT" argument to the Makefile (this was the default in 3.0.4 for m68k). But this shouldn't be the default in a 3.2.0 Debian package, but
    maybe worth a shot for a test.

    Cheers,
    --
    Charlie

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)