• after Debian update most apps crash - libffi issue?

    From Riccardo Mottola@21:1/5 to All on Sun Sep 26 14:50:02 2021
    Hi,

    I upgraded my iMac G5 to latest debian, including kernel 5.14 !
    The good thing is that the new kernel boots and X11 comes up.

    The bad news is lots of applications crash and they all have one thing
    in common, libffi.


    So e.g. a build of ArcticFox fails:
    multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
    /usr/bin/which: this version of `which' is deprecated; use `command
    -v' in scripts instead.
    Illegal instruction

    dmesg shows:
    [18439.269485] python2.7[4993]: illegal instruction (4) at
    7fffabff42fc nip 7fffabff42fc lr 7fffabff42ec code 1 in libffi.so.8.1.0[7fffabff0000+10000]
    [18439.269547] python2.7[4993]: code: 60420000 3d205858 60000000
    61295858 38800000 387e03c8 f9228590 4bffe119
    [18439.269555] python2.7[4993]: code: e8410028 60000000 7fe3fb78
    392285b8 <7c004eee> 60000000 39228950 7c004fae


    GNUMail fails to start up:
    Program received signal SIGILL, Illegal instruction.
    0x00007ffff5d08970 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    (gdb) bt
    #0 0x00007ffff5d08970 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    #1 0x00007ffff5d07f90 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    #2 0x00007ffff5d02d10 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    #3 0x00007ffff6d02be0 in cifframe_from_signature (info=<optimized
    ) at cifframe.m:196
    #4 0x00007ffff7055cf4 in -[GSFFIInvocation initWithMethodSignature:] (self=0x1002ac1c0, _cmd=<optimized out>,
    aSignature=0x1002a8180) at GSFFIInvocation.m:299
    #5 0x00007ffff6e8b130 in +[NSInvocation
    invocationWithMethodSignature:] (self=<optimized out>,
    _cmd=<optimized out>, _signature=0x1002a8180) at NSInvocation.m:332
    #6 0x00007ffff6f5cf68 in +[NSRunLoop _runLoopForThread:]
    (self=<optimized out>, _cmd=<optimized out>,
    aThread=<optimized out>) at NSRunLoop.m:790
    #7 0x00007ffff6f5a160 in +[NSRunLoop currentRunLoop]
    (self=0x7ffff7328568 <_OBJC_Class_NSRunLoop>,
    _cmd=<optimized out>) at NSRunLoop.m:827
    #8 0x00007ffff6f5b4cc in +[NSRunLoop initialize] (self=<optimized
    , _cmd=<optimized out>) at NSRunLoop.m:759
    #9 0x00007ffff6aa41e8 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libobjc.so.4
    #10 0x00007ffff6aa4368 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libobjc.so.4
    #11 0x00007ffff6aa4830 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libobjc.so.4
    #12 0x00007ffff24a4680 in -[XGServer(EventOps) setupRunLoopInputSourcesForMode:] (self=0x1003ec3d0,


    I guess not a coincidence!

    Riccardo

    --
    Sent with GNUMail from GNUstep on a Raspberry PI 4.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Sun Sep 26 15:00:02 2021
    On 9/26/21 14:56, John Paul Adrian Glaubitz wrote:
    On 9/26/21 14:54, John Paul Adrian Glaubitz wrote:
    Did you verify that downgrading the libffi package fixes the problem?

    If yes, you may file an upstream bug here [1]. The powerpc-related changes I can
    see at first glance are these [2].

    My guess would be this change:

    https://github.com/libffi/libffi/commit/4d6d2866ae43e55325e8ee96561221804602cd7a

    My recommendation would be checking out libffi from git, then build and
    install into /usr/local. Then bisect the issue and file a bug report with
    the offending commit.

    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 John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Sun Sep 26 15:00:02 2021
    Hello!

    On 9/26/21 14:36, Riccardo Mottola wrote:
    I upgraded my iMac G5 to latest debian, including kernel 5.14 !
    The good thing is that the new kernel boots and X11 comes up.

    The bad news is lots of applications crash and they all have one thing in common, libffi.


    So e.g. a build of ArcticFox fails:
    multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
    /usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
    Illegal instruction

    Did you verify that downgrading the libffi package fixes the problem?

    If yes, you may file an upstream bug here [1]. The powerpc-related changes I can
    see at first glance are these [2].

    Adrian

    [1] https://github.com/libffi/libffi
    [2] https://github.com/libffi/libffi/search?o=desc&q=powerpc&s=author-date&type=commits

    --
    .''`. 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 Riccardo Mottola@21:1/5 to glaubitz@physik.fu-berlin.de on Sun Sep 26 15:40:01 2021
    Hello Adrian,

    On 2021-09-26 13:54:33 +0100 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

    Hello!

    On 9/26/21 14:36, Riccardo Mottola wrote:
    I upgraded my iMac G5 to latest debian, including kernel 5.14 !
    The good thing is that the new kernel boots and X11 comes up.

    The bad news is lots of applications crash and they all have one
    thing in
    common, libffi.


    So e.g. a build of ArcticFox fails:
    multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
    /usr/bin/which: this version of `which' is deprecated; use `command
    -v' in
    scripts instead.
    Illegal instruction

    Did you verify that downgrading the libffi package fixes the problem?


    N, I didn't verify that yet because I have currenlty both libffi7 and
    libff8 package installed. Removing libffi 8 would break a couple of
    important packages /libp11, libpython2.7 and 3.9 - unsurprisingly -
    and also libwayland).

    GNUstep is not listed because I all have it compiled from source as a developer.

    Is there a good way to "downgrade" with aptitude or apt-get that would
    also downgrade all relativive dependencies? I guess a tree comes up. I
    did not clean my local apt cache, so I guess I have most old version
    still local.

    That's a bit a similar issue with building libffi locally. In
    /usr/local I am unsure it would be picked up. I can of course still do
    it and perhaps have GNUstep pick it up and do some tests there.

    In the meanwhile, I'm setting up to configure and build libffi locally.

    Riccardo

    --
    Sent with GNUMail from GNUstep on a Raspberry PI 4.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Sun Sep 26 15:50:01 2021
    On 9/26/21 15:39, Riccardo Mottola wrote:
    That's a bit a similar issue with building libffi locally. In /usr/local
    I am unsure it would be picked up. I can of course still do it and perhaps have GNUstep pick it up and do some tests there.

    In the meanwhile, I'm setting up to configure and build libffi locally.

    You can build libffi locally and then make your application make use of it
    by setting LD_LIBRARY_PATH=/path/to/local/libffi so that your application
    picks it up from there, e.g.

    $ LD_LIBRARY_PATH=/home/user/libffi/ python2.7

    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 Riccardo Mottola@21:1/5 to glaubitz@physik.fu-berlin.de on Sun Sep 26 19:40:02 2021
    Hi Adrian,


    On 2021-09-26 15:43:02 +0200 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

    On 9/26/21 15:39, Riccardo Mottola wrote:
    That's a bit a similar issue with building libffi locally. In
    /usr/local
    I am unsure it would be picked up. I can of course still do it and
    perhaps
    have GNUstep pick it up and do some tests there.

    In the meanwhile, I'm setting up to configure and build libffi
    locally.

    You can build libffi locally and then make your application make use
    of it
    by setting LD_LIBRARY_PATH=/path/to/local/libffi so that your
    application
    picks it up from there, e.g.

    $ LD_LIBRARY_PATH=/home/user/libffi/ python2.7

    While out to a walk, I had the same idea.. I wasn't sure it would work
    but "ldd" confirms that the local version of the library is picked up.

    Thus I got latest git of libffi from the repository you usggested.
    Configured and built without any additional parameter.

    export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

    And things works. Python does not crash and GNUstep works, as I am
    typing this right mail from my iMac.

    Now this means that thebug is not present in current upstream. Either
    it is already solved, or there is an issue in the Debian package.

    Would you like me to build the latest "release" of libffi ?

    I'd like to run libffi tests, which would be a little more certain
    instead of jjust trying out application, but it fails fro missing
    "runtest". Is that a developer package I never heard of?


    Cheers,

    Riccardo

    --
    Sent with GNUMail from iMac PowerPC 64bit running GNUstep on Debian/PPC

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Sun Sep 26 19:40:01 2021
    On 9/26/21 19:31, Riccardo Mottola wrote:
    Would you like me to build the latest "release" of libffi ?

    Yes, please test the 3.4.2 release by checking out the "v3.4.2" tag:

    $ git checkout v3.4.2

    If you can reproduce the issue then, please start bisecting with:

    $ git bisect start
    $ git bisect good HEAD
    $ git bisect bad v3.4.2

    Then you can find out which patch fixed the issue.

    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 John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Sun Sep 26 22:50:02 2021
    On 9/26/21 22:38, Riccardo Mottola wrote:
    No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work fine out of the box.

    So either the release is not well tagged, or there is an issue with the Debian package.

    You could try rebuilding the libffi Debian package locally and see if that makes any
    difference. I'll check the build logs whether the package might have been built with the compiler option "-mnative".

    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 Riccardo Mottola@21:1/5 to glaubitz@physik.fu-berlin.de on Sun Sep 26 22:40:01 2021
    Hi Adrian,


    On 2021-09-26 18:34:47 +0100 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

    On 9/26/21 19:31, Riccardo Mottola wrote:
    Would you like me to build the latest "release" of libffi ?

    Yes, please test the 3.4.2 release by checking out the "v3.4.2" tag:

    $ git checkout v3.4.2

    If you can reproduce the issue then, please start bisecting with:

    No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work
    fine out of the box.

    So either the release is not well tagged, or there is an issue with
    the Debian package.

    Riccardo

    --
    Sent with GNUMail from GNUstep on a Raspberry PI 4.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Riccardo Mottola@21:1/5 to John Paul Adrian Glaubitz on Mon Sep 27 23:50:03 2021
    Hi,

    John Paul Adrian Glaubitz wrote:
    No I cannot, 3.4.2 (cleaned, reconfigured, installed) seems to work fine out of the box.

    So either the release is not well tagged, or there is an issue with the Debian package.
    You could try rebuilding the libffi Debian package locally and see if that makes any
    difference. I'll check the build logs whether the package might have been built
    with the compiler option "-mnative".

    yes please check that - I will access this computer only next weekend,
    so for now no test, I only have my laptop with me, but 32bit might not
    be affected.

    Riccardo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Riccardo Mottola@21:1/5 to All on Tue Sep 28 00:40:01 2021
    Hi,

    just for info - the issue happens also on PowerPC G4 32bit.

    strange nobody else shares this?

    Riccardo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From kristofferfin@tuta.io@21:1/5 to All on Tue Sep 28 00:50:01 2021
    I confirm that. I had problem with Arctic fox an Fadedorb because of lack of that lib.
    On my G4 machines I have installed missing lib from Fienix repos.

    Terv, 
    Kristoffer

    --
    Wiadomość wysłana za pomocą serwisu Tutanota, oferującego bezpieczną i wolną od reklam usługę e-mail:
    https://tutanota.com

    <html>
    <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div>I confirm that. I had problem with Arctic fox an Fadedorb because of lack of that lib.<br></div><div dir="auto">On my G4 machines I have installed missing lib from Fienix repos.<br></div><div dir="auto"><br></div><div dir="auto">Terv,&nbsp;<br></div>
    <div dir="auto">Kristoffer</div><div dir="auto"><br></div><div><br></div><div>-- <br></div><div> Wiadomość wysłana za pomocą serwisu Tutanota, oferującego&nbsp;bezpieczną i wolną od reklam usługę e-mail: <br></div><div> https://tutanota.com<br></
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cameron MacPherson@21:1/5 to All on Tue Sep 28 08:50:01 2021
    i too am having problems with libffi8 on a powermac g5

    # dmesg
    ...
    [ 16.257543] fail2ban-server[384]: illegal instruction (4) at
    3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000]
    ...
    # ls -l libffi*
    -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0
    -rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0

    i went back to 7.1.0 and there are no more messages about illegal
    instructions

    cam

    On Sun, Sep 26, 2021 at 5:45 AM Riccardo Mottola <riccardo.mottola@libero.it> wrote:

    Hi,

    I upgraded my iMac G5 to latest debian, including kernel 5.14 !
    The good thing is that the new kernel boots and X11 comes up.

    The bad news is lots of applications crash and they all have one thing
    in common, libffi.


    So e.g. a build of ArcticFox fails:
    multix@PPC970FX:~/code/Arctic-Fox$ ./mach build
    /usr/bin/which: this version of `which' is deprecated; use `command
    -v' in scripts instead.
    Illegal instruction

    dmesg shows:
    [18439.269485] python2.7[4993]: illegal instruction (4) at
    7fffabff42fc nip 7fffabff42fc lr 7fffabff42ec code 1 in libffi.so.8.1.0[7fffabff0000+10000]
    [18439.269547] python2.7[4993]: code: 60420000 3d205858 60000000
    61295858 38800000 387e03c8 f9228590 4bffe119
    [18439.269555] python2.7[4993]: code: e8410028 60000000 7fe3fb78
    392285b8 <7c004eee> 60000000 39228950 7c004fae


    GNUMail fails to start up:
    Program received signal SIGILL, Illegal instruction.
    0x00007ffff5d08970 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    (gdb) bt
    #0 0x00007ffff5d08970 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    #1 0x00007ffff5d07f90 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    #2 0x00007ffff5d02d10 in ?? () from
    /usr/lib/powerpc64-linux-gnu/libffi.so.8
    #3 0x00007ffff6d02be0 in cifframe_from_signature (info=<optimized
    ) at cifframe.m:196
    #4 0x00007ffff7055cf4 in -[GSFFIInvocation initWithMethodSignature:] (self=0x1002ac1c0, _cmd=<optimized out>,
    aSignature=0x1002a8180) at GSFFIInvocation.m:299
    #5 0x00007ffff6e8b130 in +[NSInvocation
    invocationWithMethodSignature:] (self=<optimized out>,
    _cmd=<optimized out>, _signature=0x1002a8180) at NSInvocation.m:332
    #6 0x00007ffff6f5cf68 in +[NSRunLoop _runLoopForThread:]
    (self=<optimized out>, _cmd=<optimized out>,
    aThread=<optimized out>) at NSRunLoop.m:790
    #7 0x00007ffff6f5a160 in +[NSRunLoop currentRunLoop]
    (self=0x7ffff7328568 <_OBJC_Class_NSRunLoop>,
    _cmd=<optimized out>) at NSRunLoop.m:827
    #8 0x00007ffff6f5b4cc in +[NSRunLoop initialize] (self=<optimized
    , _cmd=<optimized out>) at NSRunLoop.m:759
    #9 0x00007ffff6aa41e8 in ?? () from /usr/lib/powerpc64-linux-gnu/libobjc.so.4
    #10 0x00007ffff6aa4368 in ?? () from /usr/lib/powerpc64-linux-gnu/libobjc.so.4
    #11 0x00007ffff6aa4830 in ?? () from /usr/lib/powerpc64-linux-gnu/libobjc.so.4
    #12 0x00007ffff24a4680 in -[XGServer(EventOps) setupRunLoopInputSourcesForMode:] (self=0x1003ec3d0,


    I guess not a coincidence!

    Riccardo

    --
    Sent with GNUMail from GNUstep on a Raspberry PI 4.



    <div dir="ltr"><div>i too am having problems with libffi8 on a powermac g5<span style="font-family:monospace"><br></span></div><div><br></div><div><div dir="ltr"><div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(
    0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace"># dmesg<br></span></span></span></span></span></div><div dir="ltr"><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-
    color:rgb(255,255,255)">...<br></span></span></span></span></div><div dir="ltr"><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">[   16.257543] fail2ban-server[384]: ille</
    span>gal instruction (4) at 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000]<br>...<br></span></span></span></div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);
    background-color:rgb(255,255,255)"><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"></span></span></span></span></span></span></div><div dir="ltr"><span class="gmail-gI"><span><span style="font-family:
    monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"># ls -l libffi*
    </span><br>-rw-r--r-- 1 root root 68696 Feb 20  2021 libffi.so.7.1.0 <br></span></span></span></span></span></div><div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace">-rw-r--r-- 1 root root 68720 Sep 24 00:
    00 libffi.so.8.1.0</span></span></span></span></span></div><div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace"><br></span></span></span>
    </span></span></div><div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace">i went back to 7.1.0 and there are no more messages about
    illegal instructions</span></span></span></span></span></div><div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace"><br></span></span></
    span></span></span></div><div><span class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace">cam<br></span></span></span></span></span></div><div><span
    class="gmail-gI"><span><span style="font-family:monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)"><span style="font-family:monospace"><br></span></span></span></span></span></div><div class="gmail_quote"><div dir="ltr" class="
    gmail_attr">On Sun, Sep 26, 2021 at 5:45 AM Riccardo Mottola &lt;<a href="mailto:riccardo.mottola@libero.it">riccardo.mottola@libero.it</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,
    204,204);padding-left:1ex">Hi,<br>

    I upgraded my iMac G5 to latest debian, including kernel 5.14 !<br>
    The good thing is that the new kernel boots and X11 comes up.<br>

    The bad news is lots of applications crash and they all have one thing <br>
    in common, libffi.<br>


    So e.g. a build of ArcticFox fails:<br>
    multix@PPC970FX:~/code/Arctic-Fox$ ./mach build<br>
    /usr/bin/which: this version of `which&#39; is deprecated; use `command <br> -v&#39; in scripts instead.<br>
    Illegal instruction<br>

    dmesg shows:<br>
    [18439.269485] python2.7[4993]: illegal instruction (4) at <br>
    7fffabff42fc nip 7fffabff42fc lr 7fffabff42ec code 1 in <br> libffi.so.8.1.0[7fffabff0000+10000]<br>
    [18439.269547] python2.7[4993]: code: 60420000 3d205858 60000000 <br>
    61295858 38800000 387e03c8 f9228590 4bffe119<br>
    [18439.269555] python2.7[4993]: code: e8410028 60000000 7fe3fb78 <br>
    392285b8 &lt;7c004eee&gt; 60000000 39228950 7c004fae<br>


    GNUMail fails to start up:<br>
    Program received signal SIGILL, Illegal instruction.<br>
    0x00007ffff5d08970 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libffi.so.8<br>
    (gdb) bt<br>
    #0  0x00007ffff5d08970 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libffi.so.8<br>
    #1  0x00007ffff5d07f90 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libffi.so.8<br>
    #2  0x00007ffff5d02d10 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libffi.so.8<br>
    #3  0x00007ffff6d02be0 in cifframe_from_signature (info=&lt;optimized <br> out&gt;) at cifframe.m:196<br>
    #4  0x00007ffff7055cf4 in -[GSFFIInvocation initWithMethodSignature:] <br> (self=0x1002ac1c0, _cmd=&lt;optimized out&gt;,<br>
         aSignature=0x1002a8180) at GSFFIInvocation.m:299<br>
    #5  0x00007ffff6e8b130 in +[NSInvocation <br>
    invocationWithMethodSignature:] (self=&lt;optimized out&gt;,<br>
         _cmd=&lt;optimized out&gt;, _signature=0x1002a8180) at NSInvocation.m:332<br>
    #6  0x00007ffff6f5cf68 in +[NSRunLoop _runLoopForThread:] <br> (self=&lt;optimized out&gt;, _cmd=&lt;optimized out&gt;,<br>
         aThread=&lt;optimized out&gt;) at NSRunLoop.m:790<br>
    #7  0x00007ffff6f5a160 in +[NSRunLoop currentRunLoop] <br> (self=0x7ffff7328568 &lt;_OBJC_Class_NSRunLoop&gt;,<br>
         _cmd=&lt;optimized out&gt;) at NSRunLoop.m:827<br>
    #8  0x00007ffff6f5b4cc in +[NSRunLoop initialize] (self=&lt;optimized <br> out&gt;, _cmd=&lt;optimized out&gt;) at NSRunLoop.m:759<br>
    #9  0x00007ffff6aa41e8 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libobjc.so.4<br>
    #10 0x00007ffff6aa4368 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libobjc.so.4<br>
    #11 0x00007ffff6aa4830 in ?? () from <br> /usr/lib/powerpc64-linux-gnu/libobjc.so.4<br>
    #12 0x00007ffff24a4680 in -[XGServer(EventOps) <br> setupRunLoopInputSourcesForMode:] (self=0x1003ec3d0,<br>


    I guess not a coincidence!<br>

    Riccardo<br>

    -- <br>
    Sent with GNUMail from GNUstep on a Raspberry PI 4.<br>

    </blockquote></div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Tue Sep 28 09:50:02 2021
    Hello!

    On 9/28/21 06:18, Cameron MacPherson wrote:
    i too am having problems with libffi8 on a powermac g5

    # dmesg
    ...
    [ 16.257543] fail2ban-server[384]: illegal instruction (4) at
    3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000]
    ...
    # ls -l libffi*
    -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0
    -rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0

    i went back to 7.1.0 and there are no more messages about illegal instructions

    Could you please help debugging this? I'm currently not at home and
    don't have access to my Powerbook G4.

    Please try building libffi from git as I'm still a bit skeptical that
    Ricardo built the upstream version properly. I don't see any reason
    why the regression shouldn't be a result of an upstream change but in
    the Debian package as the Debian package doesn't do anything special.

    $ apt build-dep libffi
    $ git clone https://github.com/libffi/libffi.git
    $ cd libffi
    $ ./autogen.sh && ./configure && make

    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 John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Tue Sep 28 09:50:02 2021
    Hello Riccardo!

    On 9/26/21 19:31, Riccardo Mottola wrote:
    While out to a walk, I had the same idea.. I wasn't sure it would work
    but "ldd" confirms that the local version of the library is picked up.

    Thus I got latest git of libffi from the repository you usggested. Configured and built without any additional parameter.

    export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

    And things works. Python does not crash and GNUstep works, as I am typing this right mail from my iMac.

    Please try building with "--disable-exec-static-tramp" because that's what
    the Debian package is doing now. This is the only difference I could see
    in the new Debian package.

    Otherwise, it must be some upstream change and you should be able to bisect which one it was.

    Please try some more.

    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 John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Tue Sep 28 09:30:01 2021
    Hello!

    On 9/27/21 23:43, Riccardo Mottola wrote:
    yes please check that - I will access this computer only next weekend,
    so for now no test, I only have my laptop with me, but 32bit might not
    be affected.

    It's not being built with -mnative as far I could tell from the logs.

    But you can verify whether this is the case or not by building the
    Debian package on your local machine:

    $ apt-get install devscripts
    $ dget -u https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc
    $ apt-get build-dep libffi
    $ cd libffi-3.4.2
    $ dpkg-buildpackage -B

    The resulting packages will be found in the parent folder. Install them and
    see if that fixes the problem.

    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 John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Tue Sep 28 10:50:02 2021
    Hello!

    On 9/28/21 10:33, Cameron MacPherson wrote:
    after ./autogen.sh && ./configure && make i then copied the new libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal
    instruction messages

    Did you verify that it is actually using the proper version?

    You need to make sure 100% that this version fixes it while the
    libffi.so.8.1.0 from the Debian package causes the crash.

    Also, can you check whether passing "--disable-exec-static-tramp"
    makes a difference?

    We need to find out why the Debian package causes SIGILL and we
    still don't know why. It gets particularly strange when the issue
    cannot be reproduced with the upstream source.

    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 Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 28 11:10:01 2021
    i ran apt install --reinstall libffi8, restarted the system and the
    following messages reappeared

    [ 16.874069] fail2ban-server[384]: illegal instruction (4) at
    3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in libffi.so.8.1.0[3fff7ef8d000+c000]
    [ 16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020
    00000000 00000000 00000000 60000000 60420000
    [ 16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018
    39230004 <7c004eee> 39230020 7c004fae 4bfffaf4

    after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure with --disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more messages on the console or in the logs about libfffi

    # ls -l libffi*
    lrwxrwxrwx 1 root root 15 Sep 28 01:22 libffi.so -> libffi.so.8.1.0 lrwxrwxrwx 1 root root 15 Feb 20 2021 libffi.so.7 -> libffi.so.7.1.0 -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0
    lrwxrwxrwx 1 root root 15 Sep 24 00:00 libffi.so.8 -> libffi.so.8.1.0 -rw-r--r-- 1 root root 78152 Sep 28 01:47 libffi.so.8.1.0

    september 28th is the one i just compiled replacing the one contained in
    the libff8 package. i dont know the standard way of verifying which
    library is being used.



    On Tue, Sep 28, 2021 at 1:40 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    Hello!

    On 9/28/21 10:33, Cameron MacPherson wrote:
    after ./autogen.sh && ./configure && make i then copied the new libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal instruction messages

    Did you verify that it is actually using the proper version?

    You need to make sure 100% that this version fixes it while the libffi.so.8.1.0 from the Debian package causes the crash.

    Also, can you check whether passing "--disable-exec-static-tramp"
    makes a difference?

    We need to find out why the Debian package causes SIGILL and we
    still don't know why. It gets particularly strange when the issue
    cannot be reproduced with the upstream source.

    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



    <div dir="ltr"><div>i ran apt install --reinstall libffi8, restarted the system and the following messages reappeared</div><div><br></div><div>[   16.874069] fail2ban-server[384]: illegal instruction (4) at 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90
    code 1 in libffi.so.8.1.0[3fff7ef8d000+c000]</div>[   16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020 00000000 00000000 00000000 60000000 60420000 <br><div>[   16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018 39230004
    &lt;7c004eee&gt; 39230020 7c004fae 4bfffaf4 <br></div><div><br></div><div>after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure with --disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once
    again restarted the system and no more messages on the console or in the logs about libfffi</div><div><br></div><div># ls -l libffi*<br>lrwxrwxrwx 1 root root    15 Sep 28 01:22 libffi.so -&gt; libffi.so.8.1.0<br>lrwxrwxrwx 1 root root    15 Feb 20  
    2021 libffi.so.7 -&gt; libffi.so.7.1.0<br>-rw-r--r-- 1 root root 68696 Feb 20  2021 libffi.so.7.1.0<br>lrwxrwxrwx 1 root root    15 Sep 24 00:00 libffi.so.8 -&gt; libffi.so.8.1.0<br>-rw-r--r-- 1 root root 78152 Sep 28 01:47 libffi.so.8.1.0</div><div><
    </div><div>september 28th is the one i just compiled replacing the one contained in the libff8 package.  i dont know the standard way of verifying which library is being used.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div
    dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 1:40 AM John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;
    border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>

    On 9/28/21 10:33, Cameron MacPherson wrote:<br>
    &gt; after ./autogen.sh &amp;&amp; ./configure &amp;&amp; make i then copied the new<br>
    &gt; libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to<br> &gt; /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal<br>
    &gt; instruction messages<br>

    Did you verify that it is actually using the proper version?<br>

    You need to make sure 100% that this version fixes it while the<br> libffi.so.8.1.0 from the Debian package causes the crash.<br>

    Also, can you check whether passing &quot;--disable-exec-static-tramp&quot;<br> makes a difference?<br>

    We need to find out why the Debian package causes SIGILL and we<br>
    still don&#39;t know why. It gets particularly strange when the issue<br> cannot be reproduced with the upstream source.<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 28 10:40:01 2021
    hi,

    after ./autogen.sh && ./configure && make i then copied the new
    libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to /usr/lib/powerpc64-linux-gnu and that solved it. no more illegal
    instruction messages

    On Tue, Sep 28, 2021 at 12:44 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    Hello!

    On 9/28/21 06:18, Cameron MacPherson wrote:
    i too am having problems with libffi8 on a powermac g5

    # dmesg
    ...
    [ 16.257543] fail2ban-server[384]: illegal instruction (4) at 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in libffi.so.8.1.0[3fffb427b000+c000]
    ...
    # ls -l libffi*
    -rw-r--r-- 1 root root 68696 Feb 20 2021 libffi.so.7.1.0
    -rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0

    i went back to 7.1.0 and there are no more messages about illegal instructions

    Could you please help debugging this? I'm currently not at home and
    don't have access to my Powerbook G4.

    Please try building libffi from git as I'm still a bit skeptical that
    Ricardo built the upstream version properly. I don't see any reason
    why the regression shouldn't be a result of an upstream change but in
    the Debian package as the Debian package doesn't do anything special.

    $ apt build-dep libffi
    $ git clone https://github.com/libffi/libffi.git
    $ cd libffi
    $ ./autogen.sh && ./configure && make

    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



    <div dir="ltr"><div>hi,</div><div><br></div><div dir="ltr">after ./autogen.sh &amp;&amp; ./configure &amp;&amp; make i then copied the new libffi.so.8.1.0 from ~/libffi/powerpc64-unknown-linux-gnu/.libs to</div><div dir="ltr">/usr/lib/powerpc64-linux-gnu
    and that solved it. no more illegal instruction messages<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 12:44 AM John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.
    fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>

    On 9/28/21 06:18, Cameron MacPherson wrote:<br>
    &gt; i too am having problems with libffi8 on a powermac g5<br>
    &gt; <br>
    &gt; # dmesg<br>
    &gt; ...<br>
    &gt; [   16.257543] fail2ban-server[384]: illegal instruction (4) at<br>
    &gt; 3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in<br>
    &gt; libffi.so.8.1.0[3fffb427b000+c000]<br>
    &gt; ...<br>
    &gt; # ls -l libffi*<br>
    &gt; -rw-r--r-- 1 root root 68696 Feb 20  2021 libffi.so.7.1.0<br>
    &gt; -rw-r--r-- 1 root root 68720 Sep 24 00:00 libffi.so.8.1.0<br>
    &gt; <br>
    &gt; i went back to 7.1.0 and there are no more messages about illegal<br>
    &gt; instructions<br>

    Could you please help debugging this? I&#39;m currently not at home and<br> don&#39;t have access to my Powerbook G4.<br>

    Please try building libffi from git as I&#39;m still a bit skeptical that<br> Ricardo built the upstream version properly. I don&#39;t see any reason<br>
    why the regression shouldn&#39;t be a result of an upstream change but in<br> the Debian package as the Debian package doesn&#39;t do anything special.<br>

    $ apt build-dep libffi<br>
    $ git clone <a href="https://github.com/libffi/libffi.git" rel="noreferrer" target="_blank">https://github.com/libffi/libffi.git</a><br>
    $ cd libffi<br>
    $ ./autogen.sh &amp;&amp; ./configure &amp;&amp; make<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Tue Sep 28 11:10:02 2021
    Hi Cameron!

    On 9/28/21 10:59, Cameron MacPherson wrote:
    i ran apt install --reinstall libffi8, restarted the system and the
    following messages reappeared

    [ 16.874069] fail2ban-server[384]: illegal instruction (4) at
    3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in libffi.so.8.1.0[3fff7ef8d000+c000]
    [ 16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020 00000000 00000000 00000000 60000000 60420000
    [ 16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4

    after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure with --disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more messages on the console or in the logs about libfffi

    OK, this sounds like a good verification. Thanks for testing this for me.

    Can you make another check and try the v3.4.2 upstream tag?

    $ make clean
    $ git clean -df
    $ git checkout v3.4.2
    $ ./autogen.sh && ./configure && make

    and try again? Maybe the issue was fixed between v3.4.2 and HEAD.

    september 28th is the one i just compiled replacing the one contained in
    the libff8 package. i dont know the standard way of verifying which
    library is being used.

    You can verify the library being using with the `ldd` command.

    For example:

    $ ldd `which python2.7`

    So, my next guess is that there is something wrong with the Debian source package. Maybe it's actually not version 3.4.2 that is being used.

    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 John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Tue Sep 28 12:10:02 2021
    Hi Cameron!

    On 9/28/21 11:38, Cameron MacPherson wrote:
    i recompiled everything with gcc-10 and there is no change vs gcc version 11

    As a last test, can you try rebuilding the Debian package locally and test that?

    $ apt-get install devscripts
    $ dget -u https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc
    $ apt-get build-dep libffi
    $ cd libffi-3.4.2
    $ dpkg-buildpackage -B

    Then just install the package with "dpkg -i libffi_3.4.2-2_powerpc.deb"

    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 John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Tue Sep 28 11:30:02 2021
    On 9/28/21 11:22, Cameron MacPherson wrote:
    after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.
    i am using gcc 11.2.0-7

    Ah, the compiler is a good point.

    Try building with gcc-10 instead by setting CC=gcc-10 after installing
    the gcc-10 package.

    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 Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 28 11:30:01 2021
    after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.
    i am using gcc 11.2.0-7

    On Tue, Sep 28, 2021 at 2:07 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    Hi Cameron!

    On 9/28/21 10:59, Cameron MacPherson wrote:
    i ran apt install --reinstall libffi8, restarted the system and the following messages reappeared

    [ 16.874069] fail2ban-server[384]: illegal instruction (4) at 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in libffi.so.8.1.0[3fff7ef8d000+c000]
    [ 16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020 00000000 00000000 00000000 60000000 60420000
    [ 16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018 39230004 <7c004eee> 39230020 7c004fae 4bfffaf4

    after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure
    with
    --disable-exec-static-tramp and then copied the new libffi.so.8 to /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more messages on the console or in the logs about libfffi

    OK, this sounds like a good verification. Thanks for testing this for me.

    Can you make another check and try the v3.4.2 upstream tag?

    $ make clean
    $ git clean -df
    $ git checkout v3.4.2
    $ ./autogen.sh && ./configure && make

    and try again? Maybe the issue was fixed between v3.4.2 and HEAD.

    september 28th is the one i just compiled replacing the one contained in the libff8 package. i dont know the standard way of verifying which library is being used.

    You can verify the library being using with the `ldd` command.

    For example:

    $ ldd `which python2.7`

    So, my next guess is that there is something wrong with the Debian source package. Maybe it's actually not version 3.4.2 that is being used.

    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



    <div dir="ltr"><div>after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.<span class="gmail-im"> i am using gcc 11.2.0-7<br></span></div><div><span class="gmail-
    im"></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 2:07 AM John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><
    blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Cameron!<br>

    On 9/28/21 10:59, Cameron MacPherson wrote:<br>
    &gt; i ran apt install --reinstall libffi8, restarted the system and the<br> &gt; following messages reappeared<br>
    &gt; <br>
    &gt; [   16.874069] fail2ban-server[384]: illegal instruction (4) at<br>
    &gt; 3fff7ef95970 nip 3fff7ef95970 lr 3fff7ef94f90 code 1 in<br>
    &gt; libffi.so.8.1.0[3fff7ef8d000+c000]<br>
    &gt; [   16.874154] fail2ban-server[384]: code: b1090008 f9490000 4e800020<br>
    &gt; 00000000 00000000 00000000 60000000 60420000<br>
    &gt; [   16.874176] fail2ban-server[384]: code: 81230000 712a0008 41820018<br>
    &gt; 39230004 &lt;7c004eee&gt; 39230020 7c004fae 4bfffaf4<br>
    &gt; <br>
    &gt; after rm -rf ~/libffi, git clone, autogen, this time i ran ./configure with<br>
    &gt; --disable-exec-static-tramp and then copied the new libffi.so.8 to<br> &gt; /usr/lib/powerpc64-linux-gnu/ once again restarted the system and no more<br>
    &gt; messages on the console or in the logs about libfffi<br>

    OK, this sounds like a good verification. Thanks for testing this for me.<br>

    Can you make another check and try the v3.4.2 upstream tag?<br>

    $ make clean<br>
    $ git clean -df<br>
    $ git checkout v3.4.2<br>
    $ ./autogen.sh &amp;&amp; ./configure &amp;&amp; make<br>

    and try again? Maybe the issue was fixed between v3.4.2 and HEAD.<br>

    &gt; september 28th is the one i just compiled replacing the one contained in<br>
    &gt; the libff8 package.  i dont know the standard way of verifying which<br> &gt; library is being used.<br>

    You can verify the library being using with the `ldd` command.<br>

    For example:<br>

    $ ldd `which python2.7`<br>

    So, my next guess is that there is something wrong with the Debian source<br> package. Maybe it&#39;s actually not version 3.4.2 that is being used.<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 28 11:40:01 2021
    i recompiled everything with gcc-10 and there is no change vs gcc version 11

    On Tue, Sep 28, 2021 at 2:24 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    On 9/28/21 11:22, Cameron MacPherson wrote:
    after running the commands you listed i repeated my process with the new libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them
    work.
    i am using gcc 11.2.0-7

    Ah, the compiler is a good point.

    Try building with gcc-10 instead by setting CC=gcc-10 after installing
    the gcc-10 package.

    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



    <div dir="ltr">i recompiled everything with gcc-10 and there is no change vs gcc version 11<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 2:24 AM John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@
    physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/28/21 11:22, Cameron MacPherson wrote:<br>
    &gt; after running the commands you listed i repeated my process with the new<br>
    &gt; libffi.so.8 from v3.4.2 vs HEAD and there is no change. both of them work.<br>
    &gt; i am using gcc 11.2.0-7<br>

    Ah, the compiler is a good point.<br>

    Try building with gcc-10 instead by setting CC=gcc-10 after installing<br>
    the gcc-10 package.<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Tue Sep 28 13:00:02 2021
    On 9/28/21 12:55, Cameron MacPherson wrote:
    after building and installing it locally using your commands (i had to add --no-sign to dpkg-buildpackage) it works. no illegal instructions

    Well, that's becoming intesting now. I'm going to have the packages rebuilt
    on the buildds now.

    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 Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 28 13:00:02 2021
    after building and installing it locally using your commands (i had to add --no-sign to dpkg-buildpackage) it works. no illegal instructions

    On Tue, Sep 28, 2021 at 3:08 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    Hi Cameron!

    On 9/28/21 11:38, Cameron MacPherson wrote:
    i recompiled everything with gcc-10 and there is no change vs gcc
    version 11

    As a last test, can you try rebuilding the Debian package locally and test that?

    $ apt-get install devscripts
    $ dget -u https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc
    $ apt-get build-dep libffi
    $ cd libffi-3.4.2
    $ dpkg-buildpackage -B

    Then just install the package with "dpkg -i libffi_3.4.2-2_powerpc.deb"

    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



    <div dir="ltr">after building and installing it locally using your commands (i had to add --no-sign to dpkg-buildpackage) it works. no illegal instructions<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 3:
    08 AM John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"
    Hi Cameron!<br>

    On 9/28/21 11:38, Cameron MacPherson wrote:<br>
    &gt; i recompiled everything with gcc-10 and there is no change vs gcc version 11<br>

    As a last test, can you try rebuilding the Debian package locally and test that?<br>

    $ apt-get install devscripts<br>
    $ dget -u <a href="https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc" rel="noreferrer" target="_blank">https://deb.debian.org/debian/pool/main/libf/libffi/libffi_3.4.2-2.dsc</a><br>
    $ apt-get build-dep libffi<br>
    $ cd libffi-3.4.2<br>
    $ dpkg-buildpackage -B<br>

    Then just install the package with &quot;dpkg -i libffi_3.4.2-2_powerpc.deb&quot;<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 14:00:01 2021
    On 9/28/21 12:58, John Paul Adrian Glaubitz wrote:> On 9/28/21 12:55, Cameron MacPherson wrote:
    after building and installing it locally using your commands (i had to add >> --no-sign to dpkg-buildpackage) it works. no illegal instructions

    Well, that's becoming intesting now. I'm going to have the packages rebuilt on the buildds now.

    Can you try whether this package works?

    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
    $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb

    For ppc64:

    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
    $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb

    Although the ppc64 version was built on the same buildd as the same problematic version while the powerpc version was now built on another buildd.

    So, if the problem is fixed on powerpc now, but persists on ppc64, we might have a culprit.

    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 John Paul Adrian Glaubitz@21:1/5 to All on Tue Sep 28 15:40:02 2021
    --Apple-Mail-A064C154-0FA6-41AD-AAFA-30BE9502E8DD
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable



    On Sep 28, 2021, at 3:14 PM, Riccardo Mottola <riccardo.mottola@libero.it> wrote:

    Hello Adrian

    John Paul Adrian Glaubitz wrote:
    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
    $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb

    For ppc64:

    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
    $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb

    I can only try on G4 now (and eventually later on G3). However, the
    packages mentioned to not exist anymore, did you move them or uploaded
    them elsewhere?

    It’s been moved:

    http://incoming.ports.debian.org/buildd/packages/sid/main/

    Adrian
    --Apple-Mail-A064C154-0FA6-41AD-AAFA-30BE9502E8DD
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Sep 28, 2021, at 3:14 PM, Riccardo Mottola &lt;riccardo.
    mottola@libero.it&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Hello Adrian</span><br><span></span><br><span>John Paul Adrian Glaubitz wrote:</span><br><blockquote type="cite"><span>$ wget http://incoming.ports.
    debian.org/libffi8_3.4.2-2+b1_powerpc.deb</span><br></blockquote><blockquote type="cite"><span>$ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>For ppc64:</
    span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>$ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb</span><br></blockquote><blockquote type="cite"><span>$ dpkg -i libffi8_3.4.2-2+
    b1_ppc64.deb</span><br></blockquote><span></span><br><span>I can only try on G4 now (and eventually later on G3). However, the</span><br><span>packages mentioned to not exist anymore, did you move them or uploaded</span><br><span>them elsewhere?</span><
    </div></blockquote><br><div>It’s been moved:</div><div><br></div><div>&gt;&nbsp;<a href="http://incoming.ports.debian.org/buildd/packages/sid/main/">http://incoming.ports.debian.org/buildd/packages/sid/main/</a></div><div><br></div><div>Adrian</div><
    /body></html>
    --Apple-Mail-A064C154-0FA6-41AD-AAFA-30BE9502E8DD--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Riccardo Mottola@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 15:20:01 2021
    Hello Adrian

    John Paul Adrian Glaubitz wrote:
    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
    $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb

    For ppc64:

    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
    $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb

    I can only try on G4 now (and eventually later on G3). However, the
    packages mentioned to not exist anymore, did you move them or uploaded
    them elsewhere?

    Riccardo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Riccardo Mottola@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 17:50:03 2021
    Hi Adrian


    John Paul Adrian Glaubitz wrote:


    It’s been moved:

     http://incoming.ports.debian.org/buildd/packages/sid/main/


    Thanks. I got from there libffi8_3.4.2-2+b1_powerpc.deb

    I replaced the one I compiled myself and I immediately get illegal
    instruction in a libffi-using app.

    I replaced it with the package I compiled and it works again!

    Riccardo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Tue Sep 28 19:10:04 2021
    i installed the b1 version of libffi8 and the illegal instruction messages
    are back

    [ 16.195961] fail2ban-server[384]: illegal instruction (4) at
    3fffa5270970 nip 3fffa5270970 lr 3fffa526ff90 code 1 in libffi.so.8.1.0[3fffa5268000+c000]
    [ 16.196045] fail2ban-server[384]: code: b1090008 f9490000 4e800020
    00000000 00000000 00000000 60000000 60420000
    [ 16.196067] fail2ban-server[384]: code: 81230000 712a0008 41820018
    39230004 <7c004eee> 39230020 7c004fae 4bfffaf4


    On Tue, Sep 28, 2021, 4:50 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    On 9/28/21 12:58, John Paul Adrian Glaubitz wrote:> On 9/28/21 12:55,
    Cameron MacPherson wrote:
    after building and installing it locally using your commands (i had to
    add
    --no-sign to dpkg-buildpackage) it works. no illegal instructions

    Well, that's becoming intesting now. I'm going to have the packages
    rebuilt
    on the buildds now.

    Can you try whether this package works?

    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb
    $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb

    For ppc64:

    $ wget http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb
    $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb

    Although the ppc64 version was built on the same buildd as the same problematic
    version while the powerpc version was now built on another buildd.

    So, if the problem is fixed on powerpc now, but persists on ppc64, we might have a culprit.

    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



    <div dir="auto">i installed the b1 version of libffi8 and the illegal instruction messages are back<div dir="auto"><br></div><div dir="auto"><div dir="auto">[   16.195961] fail2ban-server[384]: illegal instruction (4) at 3fffa5270970 nip 3fffa5270970
    lr 3fffa526ff90 code 1 in libffi.so.8.1.0[3fffa5268000+c000]</div><div dir="auto">[   16.196045] fail2ban-server[384]: code: b1090008 f9490000 4e800020 00000000 00000000 00000000 60000000 60420000</div><div dir="auto">[   16.196067] fail2ban-server[
    384]: code: 81230000 712a0008 41820018 39230004 &lt;7c004eee&gt; 39230020 7c004fae 4bfffaf4</div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021, 4:50 AM John Paul Adrian Glaubitz &
    lt;<a href="mailto:glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/28/21 12:58, John Paul Adrian Glaubitz wrote:&
    gt; On 9/28/21 12:55, Cameron MacPherson wrote:<br>
    &gt;&gt; after building and installing it locally using your commands (i had to add<br>
    &gt;&gt; --no-sign to dpkg-buildpackage) it works. no illegal instructions<br> &gt; <br>
    &gt; Well, that&#39;s becoming intesting now. I&#39;m going to have the packages rebuilt<br>
    &gt; on the buildds now.<br>

    Can you try whether this package works?<br>

    $ wget <a href="http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb" rel="noreferrer noreferrer" target="_blank">http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_powerpc.deb</a><br>
    $ dpkg -i libffi8_3.4.2-2+b1_powerpc.deb<br>

    For ppc64:<br>

    $ wget <a href="http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb" rel="noreferrer noreferrer" target="_blank">http://incoming.ports.debian.org/libffi8_3.4.2-2+b1_ppc64.deb</a><br>
    $ dpkg -i libffi8_3.4.2-2+b1_ppc64.deb<br>

    Although the ppc64 version was built on the same buildd as the same problematic<br>
    version while the powerpc version was now built on another buildd.<br>

    So, if the problem is fixed on powerpc now, but persists on ppc64, we might<br> have a culprit.<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank" rel="noreferrer">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank" rel="noreferrer">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 22:00:01 2021
    Hi!

    On 9/28/21 21:34, John Paul Adrian Glaubitz wrote:
    OK. I'm regenerating the chroots on the build servers now and then
    trigger another rebuild of the package. If that still doesn't help,
    we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.

    In the meantime, could you please perform another experiment and check whether the libffi_3.4.2-1 package is affected as well?

    You can fetch it from here:

    powerpc:

    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi8_3.4.2-1_powerpc.deb

    ppc64:

    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi8_3.4.2-1_ppc64.deb

    The -dev packages can be found here if necessary:

    powerpc:

    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb

    ppc64:

    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi-dev_3.4.2-1_ppc64.deb

    If these package work, we know it's a bug with the build environment (compiler, binutils etc).

    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 John Paul Adrian Glaubitz@21:1/5 to Riccardo Mottola on Tue Sep 28 21:40:01 2021
    Hello!

    On 9/28/21 17:46, Riccardo Mottola wrote:
    I did this on my PowerBook G4 .
    I had some issues with build-dep - it doesn't like my deb-src in the
    sources file:

    apt-get build-dep libffi
    Reading package lists... Done
    E: You must put some 'deb-src' URIs in your sources.list

    I have:
    deb-src http://deb.debian.org/debian unstable main
    deb-src http://deb.debian.org/debian experimental main

    do we have our own for "ports" ? anyway, I solved dependencies manually.

    Normally this sources.list should work:

    # binary default
    deb http://ftp.ports.debian.org/debian-ports/ unstable main
    deb http://incoming.ports.debian.org/buildd/ unstable main
    deb http://ftp.ports.debian.org/debian-ports/ unreleased main

    # contrib and non-free arch:all packages (i.e. firmware)
    deb [arch=all] http://ftp.debian.org/debian/ unstable contrib non-free

    # source
    deb-src http://ftp.debian.org/debian/ unstable main
    deb-src http://incoming.debian.org/debian-buildd/ buildd-unstable main

    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 Lennart Sorensen@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 22:30:02 2021
    On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
    OK. I'm regenerating the chroots on the build servers now and then
    trigger another rebuild of the package. If that still doesn't help,
    we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.

    Would this be a problem:

    powerpc*)
    cputype=`((grep cpu /proc/cpuinfo | head -n 1 | cut -d: -f2 | cut -d, -f1 | $SED 's/ //g') ; /usr/bin/machine ; /bin/machine; grep CPU /var/run/dmesg.boot | head -n 1 | cut -d" " -f2) 2> /dev/null`
    cputype=`echo $cputype | $SED -e 's/ppc//g;s/ *//g'`
    case $cputype in
    *750*) ax_gcc_arch="750 G3" ;;
    *740[[0-9]]*) ax_gcc_arch="$cputype 7400 G4" ;;
    *74[[4-5]][[0-9]]*) ax_gcc_arch="$cputype 7450 G4" ;;
    *74[[0-9]][[0-9]]*) ax_gcc_arch="$cputype G4" ;;
    *970*) ax_gcc_arch="970 G5 power4";;
    *POWER4*|*power4*|*gq*) ax_gcc_arch="power4 970";;
    *POWER5*|*power5*|*gr*|*gs*) ax_gcc_arch="power5 power4 970";;
    603ev|8240) ax_gcc_arch="$cputype 603e 603";;
    *POWER7*) ax_gcc_arch="power7";;
    *POWER8*) ax_gcc_arch="power8";;
    *POWER9*) ax_gcc_arch="power9";;
    *POWER10*) ax_gcc_arch="power10";;
    *) ax_gcc_arch=$cputype ;;
    esac
    ax_gcc_arch="$ax_gcc_arch powerpc"
    ;;

    I saw that in m4/ax_gcc_archflag.m4

    I guess related would be this configure option:
    --with-gcc-arch=<arch> use architecture <arch> for gcc -march/-mtune,
    instead of guessing

    --
    Len Sorensen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lennart Sorensen@21:1/5 to Lennart Sorensen on Tue Sep 28 22:40:02 2021
    On Tue, Sep 28, 2021 at 04:26:04PM -0400, Lennart Sorensen wrote:
    On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
    OK. I'm regenerating the chroots on the build servers now and then
    trigger another rebuild of the package. If that still doesn't help,
    we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.

    Would this be a problem:

    powerpc*)
    cputype=`((grep cpu /proc/cpuinfo | head -n 1 | cut -d: -f2 | cut -d, -f1 | $SED 's/ //g') ; /usr/bin/machine ; /bin/machine; grep CPU /var/run/dmesg.boot | head -n 1 | cut -d" " -f2) 2> /dev/null`
    cputype=`echo $cputype | $SED -e 's/ppc//g;s/ *//g'`
    case $cputype in
    *750*) ax_gcc_arch="750 G3" ;;
    *740[[0-9]]*) ax_gcc_arch="$cputype 7400 G4" ;;
    *74[[4-5]][[0-9]]*) ax_gcc_arch="$cputype 7450 G4" ;;
    *74[[0-9]][[0-9]]*) ax_gcc_arch="$cputype G4" ;;
    *970*) ax_gcc_arch="970 G5 power4";;
    *POWER4*|*power4*|*gq*) ax_gcc_arch="power4 970";;
    *POWER5*|*power5*|*gr*|*gs*) ax_gcc_arch="power5 power4 970";;
    603ev|8240) ax_gcc_arch="$cputype 603e 603";;
    *POWER7*) ax_gcc_arch="power7";;
    *POWER8*) ax_gcc_arch="power8";;
    *POWER9*) ax_gcc_arch="power9";;
    *POWER10*) ax_gcc_arch="power10";;
    *) ax_gcc_arch=$cputype ;;
    esac
    ax_gcc_arch="$ax_gcc_arch powerpc"
    ;;

    I saw that in m4/ax_gcc_archflag.m4

    I guess related would be this configure option:
    --with-gcc-arch=<arch> use architecture <arch> for gcc -march/-mtune,
    instead of guessing

    Or maybe:
    --enable-portable-binary
    disable compiler optimizations that would produce
    unportable binaries

    --
    Len Sorensen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lennart Sorensen@21:1/5 to John Paul Adrian Glaubitz on Tue Sep 28 22:40:02 2021
    On Tue, Sep 28, 2021 at 10:27:59PM +0200, John Paul Adrian Glaubitz wrote:
    Yes. And this is not acceptable because they are manipulating the baseline.

    Thanks for catching this. This is our bug!

    I would be surprised if powerpc is the only architecture bitten by this.
    What is i386 being compiled with?

    --
    Len Sorensen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cameron MacPherson@21:1/5 to glaubitz@physik.fu-berlin.de on Wed Sep 29 00:40:01 2021
    i can confirm that the ppc64 snapshot packages work without illegal instructions

    On Tue, Sep 28, 2021 at 12:54 PM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

    Hi!

    On 9/28/21 21:34, John Paul Adrian Glaubitz wrote:
    OK. I'm regenerating the chroots on the build servers now and then
    trigger another rebuild of the package. If that still doesn't help,
    we know there is some runtime detection which enables these instructions during build and I have to start looking into the source code.

    In the meantime, could you please perform another experiment and check whether
    the libffi_3.4.2-1 package is affected as well?

    You can fetch it from here:

    powerpc:


    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi8_3.4.2-1_powerpc.deb

    ppc64:


    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi8_3.4.2-1_ppc64.deb

    The -dev packages can be found here if necessary:

    powerpc:


    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb

    ppc64:


    http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi-dev_3.4.2-1_ppc64.deb

    If these package work, we know it's a bug with the build environment (compiler, binutils etc).

    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


    <div dir="ltr">i can confirm that the ppc64 snapshot packages work without illegal instructions<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 28, 2021 at 12:54 PM John Paul Adrian Glaubitz &lt;<a href="mailto:
    glaubitz@physik.fu-berlin.de">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>

    On 9/28/21 21:34, John Paul Adrian Glaubitz wrote:<br>
    &gt; OK. I&#39;m regenerating the chroots on the build servers now and then<br> &gt; trigger another rebuild of the package. If that still doesn&#39;t help,<br>
    &gt; we know there is some runtime detection which enables these instructions<br>
    &gt; during build and I have to start looking into the source code.<br>

    In the meantime, could you please perform another experiment and check whether<br>
    the libffi_3.4.2-1 package is affected as well?<br>

    You can fetch it from here:<br>

    powerpc:<br>

    &gt; <a href="http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi8_3.4.2-1_powerpc.deb" rel="noreferrer" target="_blank">http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/
    libf/libffi/libffi8_3.4.2-1_powerpc.deb</a><br>

    ppc64:<br>

    &gt; <a href="http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi8_3.4.2-1_ppc64.deb" rel="noreferrer" target="_blank">http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/
    libffi/libffi8_3.4.2-1_ppc64.deb</a><br>

    The -dev packages can be found here if necessary:<br>

    powerpc:<br>

    &gt; <a href="http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb" rel="noreferrer" target="_blank">http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-powerpc/
    main/libf/libffi/libffi-dev_3.4.2-1_powerpc.deb</a><br>

    ppc64:<br>

    &gt; <a href="http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/libf/libffi/libffi-dev_3.4.2-1_ppc64.deb" rel="noreferrer" target="_blank">http://snapshot.debian.org/archive/debian-ports/20210716T200121Z/pool-ppc64/main/
    libf/libffi/libffi-dev_3.4.2-1_ppc64.deb</a><br>

    If these package work, we know it&#39;s a bug with the build environment (compiler, binutils etc).<br>

    Adrian<br>

    -- <br>
     .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
    : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
    `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
      `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br> </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Paul Adrian Glaubitz@21:1/5 to John Paul Adrian Glaubitz on Wed Sep 29 00:40:02 2021
    On 9/28/21 22:27, John Paul Adrian Glaubitz wrote:
    Yes. And this is not acceptable because they are manipulating the baseline.

    And just for confirmation. After closely inspecting the build log, it becomes obvious that "-mcpu=power8" is actually passed to GCC during build.

    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 John Paul Adrian Glaubitz@21:1/5 to Cameron MacPherson on Wed Sep 29 00:50:01 2021
    On 9/29/21 00:36, Cameron MacPherson wrote:
    i can confirm that the ppc64 snapshot packages work without illegal instructions

    Comparing the build logs, it seems that this an issue with the newer version
    of autoconf that was used to build version 3.4.2-2. Looking at the log for 3.4.2-2, a lot of autoconf warnings can be seen which are not present in the log for 3.4.1-1.

    https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.4.2-1&stamp=1626443428&raw=0
    https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.4.2-2&stamp=1632868252&raw=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)