Hi all,

just to note that the libffi issues are back.
I believe Adrian put in some patched version with a workaround, which
with the latest update stopped working again?



Riccardo

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

On 10/25/21 12:08, Riccardo Mottola wrote:

just to note that the libffi issues are back.
I believe Adrian put in some patched version with a workaround, which
with the latest update stopped working again?

Yes, that's because:

a) Upstream doesn't care and has not even looked at the issue yet:

https://github.com/libffi/libffi/issues/662

b) Debian's libffi maintainer hasn't understood the problem and assume it's
just a matter of passing the right configure option. It isn't so I reopened
the bug reportÖ

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223

I don't know what else to do and honestly, I can't fix all these bugs myself, I'm
not even paid for doing that.

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)

would it be helpful if all of us affected contributed to the bug report?
the squeaky wheel gets the grease method sometimes works

On Mon, Oct 25, 2021, 11:10 AM Riccardo Mottola <riccardo.mottola@libero.it> wrote:

Hi Adrian
,

John Paul Adrian Glaubitz wrote:

a) Upstream doesn't care and has not even looked at the issue yet:

That's worrying.

https://github.com/libffi/libffi/issues/662

b) Debian's libffi maintainer hasn't understood the problem and assume

it's

just a matter of passing the right configure option. It isn't so I

reopened

the bug reportÖ

I didn't notice it was reopened, but indeed, he writes "believes" issue
is closed, but facts are different :)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223

I don't know what else to do and honestly, I can't fix all these bugs

myself, I'm

not even paid for doing that.

Adrian, I wasn't implying you should do it and I thanks for your work, I
just noted that things broke again. First part is diagnosing the issue
and hoping that maintainers and/or upstream work on it, which was not
the case.

What could be of use? forking libffi and attempting to patch all
configure warnings and generate a big patch and a pull-request?

Riccardo

<div dir="auto">would it be helpful if all of us affected contributed to the bug report?  the squeaky wheel gets the grease method sometimes works</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 25, 2021, 11:10 AM
Riccardo Mottola &lt;<a href="mailto:riccardo.mottola@libero.it" target="_blank" rel="noreferrer">riccardo.mottola@libero.it</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Adrian<br>
,<br>

John Paul Adrian Glaubitz wrote:<br>
&gt;<br>
&gt; a) Upstream doesn&#39;t care and has not even looked at the issue yet:<br>

That&#39;s worrying.<br>


&gt;<br>
&gt;&gt; <a href="https://github.com/libffi/libffi/issues/662" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/libffi/libffi/issues/662</a><br>
&gt; b) Debian&#39;s libffi maintainer hasn&#39;t understood the problem and assume it&#39;s<br>
&gt;    just a matter of passing the right configure option. It isn&#39;t so I reopened<br>
&gt;    the bug reportÖ<br>

I didn&#39;t notice it was reopened, but indeed, he writes &quot;believes&quot; issue<br>
is closed, but facts are different :)<br>

&gt;<br>
&gt;&gt; <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223" rel="noreferrer noreferrer noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223</a><br>
&gt; I don&#39;t know what else to do and honestly, I can&#39;t fix all these bugs myself, I&#39;m<br>
&gt; not even paid for doing that.<br>

Adrian, I wasn&#39;t implying you should do it and I thanks for your work, I<br>
just noted that things broke again. First part is diagnosing the issue<br>
and hoping that maintainers and/or upstream work on it, which was not<br>
the case.<br>

What could be of use? forking libffi and attempting to patch all<br>
configure warnings and generate a big patch and a pull-request?<br>


Riccardo<br>

</blockquote></div>

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

Hi Adrian
,

John Paul Adrian Glaubitz wrote:

a) Upstream doesn't care and has not even looked at the issue yet:

That's worrying.

https://github.com/libffi/libffi/issues/662

b) Debian's libffi maintainer hasn't understood the problem and assume it's
just a matter of passing the right configure option. It isn't so I reopened
the bug reportÖ

I didn't notice it was reopened, but indeed, he writes "believes" issue
is closed, but facts are different :)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223

I don't know what else to do and honestly, I can't fix all these bugs myself, I'm
not even paid for doing that.

Adrian, I wasn't implying you should do it and I thanks for your work, I
just noted that things broke again. First part is diagnosing the issue
and hoping that maintainers and/or upstream work on it, which was not
the case.

What could be of use? forking libffi and attempting to patch all
configure warnings and generate a big patch and a pull-request?


Riccardo

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

On 10/25/21 20:11, Riccardo Mottola wrote:

Adrian, I wasn't implying you should do it and I thanks for your work, I
just noted that things broke again. First part is diagnosing the issue
and hoping that maintainers and/or upstream work on it, which was not
the case.

I know that it was broken again which is why I reopened the bug. Matthias thought
the issue was a missing configure parameter, but that's not the case. The problem
is that autoconf decided to change their syntax in an incompatible way which results
in the configure script being borked and not functioning correctly.

What could be of use? forking libffi and attempting to patch all
configure warnings and generate a big patch and a pull-request?

The configure script is generated by autoconf, it's not handwritten. As you
can see from the build log [1], autoconf spews a plethora of warnings which means it's not compatible with the old autoconf files found in libffi.

We could try switching to an older version of autoconf for this package.

Adrian

[1] https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=ppc64&ver=3.4.2-3&stamp=1633957534&raw=0

--
.''`. 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)

On 10/25/21 12:11, John Paul Adrian Glaubitz wrote:

b) Debian's libffi maintainer hasn't understood the problem and assume it's
just a matter of passing the right configure option. It isn't so I reopened
the bug reportÖ

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223

So, there is an update. A fellow Debian Developer suggested on #debian-devel that
the configure option "--without-gcc-arch" will actually fix the problem and it did.

I will build the package manually with that option and upload it, the Debian's libffi maintainer will hopefully shortly follow up with an updated 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)

On 11/2/21 21:59, Cameron MacPherson wrote:

i got the 3.4.2-3+ports package after apt upgrade -t experimental and there are no illegal instructions

As I expected. The build log didn't have any traces of "-mcpu=power8".

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)

i got the 3.4.2-3+ports package after apt upgrade -t experimental and there
are no illegal instructions

On Fri, Oct 29, 2021 at 5:43 AM John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:

On 10/25/21 12:11, John Paul Adrian Glaubitz wrote:

b) Debian's libffi maintainer hasn't understood the problem and assume

it's

just a matter of passing the right configure option. It isn't so I

reopened

the bug reportÖ

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223

So, there is an update. A fellow Debian Developer suggested on
#debian-devel that
the configure option "--without-gcc-arch" will actually fix the problem
and it
did.

I will build the package manually with that option and upload it, the Debian's
libffi maintainer will hopefully shortly follow up with an updated 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 got the 3.4.2-3+ports package after apt upgrade -t experimental and there are no illegal instructions<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 29, 2021 at 5:43 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 10/25/21 12:11, John Paul Adrian
Glaubitz wrote:<br>
&gt; b) Debian&#39;s libffi maintainer hasn&#39;t understood the problem and assume it&#39;s<br>
&gt;    just a matter of passing the right configure option. It isn&#39;t so I reopened<br>
&gt;    the bug reportÖ<br>
&gt; <br>
&gt;&gt; <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223" rel="noreferrer" target="_blank">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995223</a><br>

So, there is an update. A fellow Debian Developer suggested on #debian-devel that<br>
the configure option &quot;--without-gcc-arch&quot; will actually fix the problem and it<br>
did.<br>

I will build the package manually with that option and upload it, the Debian&#39;s<br>
libffi maintainer will hopefully shortly follow up with an updated 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)

you have to add the following to your /etc/apt/sources.list to get the experimental packages

deb http://ftp.ports.debian.org/debian-ports/ experimental main

see here
https://wiki.debian.org/DebianExperimental


On Wed, Nov 3, 2021, 10:42 AM Ken Cunningham <
ken.cunningham.webuse@gmail.com> wrote:

It appears that when building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:

https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241

case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes
-mcpu= -m";; esac

The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.

This must happen with any build that uses this ax_gcc_archflag.m4 macro.

I wonder why powerpc* is excluded? Seems like this line should rather be:

case $host_cpu in i*86|x86_64*|powerpc*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac

Ken

PS. Although I did not as yet sort out getting the “experimental” packages
(I keep getting an error when I try to use that option), building libffi in
a couple of minutes on the local machine and installing that of course
works easily. — K

On Nov 2, 2021, at 2:01 PM, John Paul Adrian Glaubitz <

glaubitz@physik.fu-berlin.de> wrote:

On 11/2/21 21:59, Cameron MacPherson wrote:

i got the 3.4.2-3+ports package after apt upgrade -t experimental and there
are no illegal instructions

As I expected. The build log didn't have any traces of "-mcpu=power8".

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"><div dir="auto">you have to add the following to your /etc/apt/sources.list to get the experimental packages</div><div dir="auto"><br></div><div dir="auto">deb <a href="http://ftp.ports.debian.org/debian-ports/" target="_blank" rel="
noreferrer">http://ftp.ports.debian.org/debian-ports/</a> experimental main<br></div><div dir="auto"><br></div><div dir="auto">see here</div><div dir="auto"></div><a href="https://wiki.debian.org/DebianExperimental" rel="noreferrer noreferrer" target="_
blank">https://wiki.debian.org/DebianExperimental</a><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Nov 3, 2021, 10:42 AM Ken Cunningham &lt;<a href="mailto:ken.cunningham.
webuse@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">ken.cunningham.webuse@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It appears that when
building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:<br>

<a href="https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241</a><br>

  case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes=&quot;$flag_prefixes -mcpu= -m&quot;;; esac<br>



The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.<br>

This must happen with any build that uses this ax_gcc_archflag.m4 macro.<br>

I wonder why powerpc* is excluded? Seems like this line should rather be:<br>

  case $host_cpu in i*86|x86_64*|powerpc*|amd64*) flag_prefixes=&quot;$flag_prefixes -mcpu= -m&quot;;; esac<br>


Ken<br>

PS. Although I did not as yet sort out getting the “experimental” packages (I keep getting an error when I try to use that option), building libffi in a couple of minutes on the local machine and installing that of course works easily. — K<br>


&gt; On Nov 2, 2021, at 2:01 PM, John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br>
&gt; <br>
&gt; On 11/2/21 21:59, Cameron MacPherson wrote:<br>
&gt;&gt; i got the 3.4.2-3+ports package after apt upgrade -t experimental and there<br>
&gt;&gt; are no illegal instructions<br>
&gt; <br>
&gt; As I expected. The build log didn&#39;t have any traces of &quot;-mcpu=power8&quot;.<br>
&gt; <br>
&gt; Adrian<br>
&gt; <br>
&gt; -- <br>
&gt; .&#39;&#39;`.  John Paul Adrian Glaubitz<br>
&gt; : :&#39; :  Debian Developer - <a href="mailto:glaubitz@debian.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">glaubitz@debian.org</a><br>
&gt; `. `&#39;   Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
&gt;  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913<br> &gt; <br>

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

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

--Apple-Mail-A7DC2148-B553-42FA-A2BB-F03F3559E759
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ken!

On Nov 3, 2021, at 6:43 PM, Ken Cunningham <ken.cunningham.webuse@gmail.com> wrote:

It appears that when building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:

https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241

case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac

The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.

The problem is not exclusive to PowerPC but also SPARC and 32-bit x86. It used to work before with version 3.4.2 in experimental:

See: https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.4.2-1&stamp=1626443428&raw=0

I‘m pretty confident that my analysis is correct and the problem is triggered by the new autoconf version.

Adrian
--Apple-Mail-A7DC2148-B553-42FA-A2BB-F03F3559E759
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">Hi Ken!</div><div dir="ltr"><br><blockquote type="cite">On Nov 3, 2021, at 6:43 PM, Ken Cunningham &lt;ken.
cunningham.webuse@gmail.com&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>It appears that when building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:</span><br><span><
/span><br><span>https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241</span><br><span></span><br><span> &nbsp;case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac</span><br><span></span><br><span></span>
<br><span></span><br><span>The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.</span></div></blockquote><br><div>The problem is not exclusive to
PowerPC but also SPARC and 32-bit x86. It used to work before with version 3.4.2 in experimental:</div><div><br></div><div>See:&nbsp;<a href="https://buildd.debian.org/status/fetch.php?pkg=libffi&amp;arch=powerpc&amp;ver=3.4.2-1&amp;stamp=1626443428&amp;
raw=0">https://buildd.debian.org/status/fetch.php?pkg=libffi&amp;arch=powerpc&amp;ver=3.4.2-1&amp;stamp=1626443428&amp;raw=0</a></div><div><br></div><div>I‘m pretty confident that my analysis is correct and the problem is triggered by the new autoconf
version.</div><div><br></div><div>Adrian</div></body></html> --Apple-Mail-A7DC2148-B553-42FA-A2BB-F03F3559E759--

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

It appears that when building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:

https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241

case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac



The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.

This must happen with any build that uses this ax_gcc_archflag.m4 macro.

I wonder why powerpc* is excluded? Seems like this line should rather be:

case $host_cpu in i*86|x86_64*|powerpc*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac


Ken

PS. Although I did not as yet sort out getting the “experimental” packages (I keep getting an error when I try to use that option), building libffi in a couple of minutes on the local machine and installing that of course works easily. — K

On Nov 2, 2021, at 2:01 PM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

On 11/2/21 21:59, Cameron MacPherson wrote:

i got the 3.4.2-3+ports package after apt upgrade -t experimental and there >> are no illegal instructions

As I expected. The build log didn't have any traces of "-mcpu=power8".

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)

Thank you for the hint! — that work just perfectly.

Best,

Ken

On Nov 3, 2021, at 11:01 AM, Cameron MacPherson <cameron.macpherson@gmail.com> wrote:

you have to add the following to your /etc/apt/sources.list to get the experimental packages

deb http://ftp.ports.debian.org/debian-ports/ <http://ftp.ports.debian.org/debian-ports/> experimental main

see here
https://wiki.debian.org/DebianExperimental <https://wiki.debian.org/DebianExperimental>

On Wed, Nov 3, 2021, 10:42 AM Ken Cunningham <ken.cunningham.webuse@gmail.com <mailto:ken.cunningham.webuse@gmail.com>> wrote:
It appears that when building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:

https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241 <https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241>

case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac

The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.

This must happen with any build that uses this ax_gcc_archflag.m4 macro.

I wonder why powerpc* is excluded? Seems like this line should rather be:

case $host_cpu in i*86|x86_64*|powerpc*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac

Ken

PS. Although I did not as yet sort out getting the “experimental” packages (I keep getting an error when I try to use that option), building libffi in a couple of minutes on the local machine and installing that of course works easily. — K

On Nov 2, 2021, at 2:01 PM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de <mailto:glaubitz@physik.fu-berlin.de>> wrote:

On 11/2/21 21:59, Cameron MacPherson wrote:

i got the 3.4.2-3+ports package after apt upgrade -t experimental and there
are no illegal instructions

As I expected. The build log didn't have any traces of "-mcpu=power8".

Adrian

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

<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thank you for the hint! — that work just perfectly.<div class=""

<br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Ken<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 3, 2021, at 11:01 AM, Cameron MacPherson &lt;<a href="mailto:cameron.

macpherson@gmail.com" class="">cameron.macpherson@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div dir="auto" class="">you have to add the following to your /etc/apt/sources.list to get the
experimental packages</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">deb <a href="http://ftp.ports.debian.org/debian-ports/" target="_blank" rel="noreferrer" class="">http://ftp.ports.debian.org/debian-ports/</a> experimental
main<br class=""></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">see here</div><div dir="auto" class=""></div><a href="https://wiki.debian.org/DebianExperimental" rel="noreferrer noreferrer" target="_blank" class="">https://
wiki.debian.org/DebianExperimental</a><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Nov 3, 2021, 10:42 AM Ken Cunningham &lt;<a href="mailto:
ken.cunningham.webuse@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank" class="">ken.cunningham.webuse@gmail.com</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-
left:1ex">It appears that when building portable code, the ax_gcc_archflag.m4 macro clears -mcpu for almost every arch except powerpc:<br class="">
<br class="">
<a href="https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L241</a><br class=""

<br class="">
&nbsp; case $host_cpu in i*86|x86_64*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac<br class="">
<br class="">
<br class="">
<br class="">
The fact that PowerPC is excluded must result in m4 passing the “-mcpu=“ flag matching the buildbot’s CPU, and breaks everything older than the buildbot.<br class="">
<br class="">
This must happen with any build that uses this ax_gcc_archflag.m4 macro.<br class="">
<br class="">
I wonder why powerpc* is excluded? Seems like this line should rather be:<br class="">
<br class="">
&nbsp; case $host_cpu in i*86|x86_64*|powerpc*|amd64*) flag_prefixes="$flag_prefixes -mcpu= -m";; esac<br class="">
<br class="">
<br class="">
Ken<br class="">
<br class="">
PS. Although I did not as yet sort out getting the “experimental” packages (I keep getting an error when I try to use that option), building libffi in a couple of minutes on the local machine and installing that of course works easily. — K<br class=

<br class="">
<br class="">
&gt; On Nov 2, 2021, at 2:01 PM, John Paul Adrian Glaubitz &lt;<a href="mailto:glaubitz@physik.fu-berlin.de" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">glaubitz@physik.fu-berlin.de</a>&gt; wrote:<br class="">
&gt; <br class="">
&gt; On 11/2/21 21:59, Cameron MacPherson wrote:<br class="">
&gt;&gt; i got the 3.4.2-3+ports package after apt upgrade -t experimental and there<br class="">
&gt;&gt; are no illegal instructions<br class="">
&gt; <br class="">
&gt; As I expected. The build log didn't have any traces of "-mcpu=power8".<br class="">
&gt; <br class="">
&gt; Adrian<br class="">
&gt; <br class="">
&gt; -- <br class="">
&gt; .''`.&nbsp; John Paul Adrian Glaubitz<br class="">
&gt; : :' :&nbsp; Debian Developer - <a href="mailto:glaubitz@debian.org" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">glaubitz@debian.org</a><br class="">
&gt; `. `'&nbsp; &nbsp;Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank" class="">glaubitz@physik.fu-berlin.de</a><br class="">
&gt;&nbsp; `-&nbsp; &nbsp; GPG: 62FF 8A75 84E0 2956 9546&nbsp; 0006 7426 3B37 F5B5 F913<br class="">
&gt; <br class="">
<br class="">
</blockquote></div></div></div>
</div></blockquote></div><br class=""></div></body></html>

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

On 12/11/21 19:14, Riccardo Mottola wrote:

How is the current situation? I had an "fixed" package installed (I don't remember
if it was your build or one of mines) that got replaced during an upgrade because
it had a newver version and it is still broken.

There is a +ports package on ppc64:

http://ftp.ports.debian.org/debian-ports/pool-ppc64/main/libf/libffi/

Does this issue affect you on 32-bit powerpc as well? If yes, I need to manually update
the 32-bit package as well.

Matthias hasn't updated the libffi package yet, despite there being an RC bug open with
instructions on how to fix it. I have already pinged him several times.

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)

Hi,


On 2021-11-03 19:09:05 +0100 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

The problem is not exclusive to PowerPC but also SPARC and 32-bit x86. It used to work before with version 3.4.2 in experimental:

See: https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=powerpc&ver=3.4.2-1&stamp=1626443428&raw=0

I�m pretty confident that my analysis is correct and the problem is triggered by the new autoconf version.

How is the current situation? I had an "fixed" package installed (I don't remember if it was your build or one of mines) that got replaced during an upgrade because it had a newver version and it is still broken.

Riccardo

--
Sent with GNUMail running on MacOS 10.7

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

On Sat, Dec 11, 2021 at 07:23:51PM +0100, John Paul Adrian Glaubitz wrote:

On 12/11/21 19:14, Riccardo Mottola wrote:

How is the current situation? I had an "fixed" package installed (I don't remember
if it was your build or one of mines) that got replaced during an upgrade because
it had a newver version and it is still broken.

There is a +ports package on ppc64:

http://ftp.ports.debian.org/debian-ports/pool-ppc64/main/libf/libffi/

Does this issue affect you on 32-bit powerpc as well? If yes, I need to manually update
the 32-bit package as well.

Matthias hasn't updated the libffi package yet, despite there being an RC bug open with
instructions on how to fix it. I have already pinged him several times.

I ran into the issue on my 32-bit powerpc:

[ 92.119397] unattended-upgr[627]: illegal instruction (4) at ed78a00 nip ed78a00 lr ed789f8 code 1 in libffi.so.8.1.0[ed76000+9000]
[ 92.119499] unattended-upgr[627]: code: 83e1001c 38210020 7c0803a6 4e800020 3d205858 38800000 61295858 387f01e8
[ 92.119516] unattended-upgr[627]: code: 913f0000 48004c3d 393f0014 7fa3eb78 <7c004eee> 393f01e4 7c004fae 48004b55

(ins)efraim@g4:~$ apt-cache policy libffi8
libffi8:
Installed: 3.4.2-3
Candidate: 3.4.2-3
Version table:
*** 3.4.2-3 500
500 http://deb.debian.org/debian-ports sid/main powerpc Packages
100 /var/lib/dpkg/status

I haven't dug into it at all yet.

--
Efraim Flashner <efraim@flashner.co.il> רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmG1vcYACgkQQarn3Mo9 g1Gg9hAAomupjtutjtxp6wX2QqdXsXwPjzNhJNplLOh7ajUfkuR4RtgNuRvPU9zW FR5ou8lOotpKtjKhBgDRQ3jSyFlsbKWfE8Q9zMaMk69KHf6p0lLjFUIGLfI20nwW /749c8kSxTkFQ0/M3z7ohmTRTXuqiPr8Ea9GkaM+hL/2pYuv9yU/hfZZ/lcgTKpr QZbCFx+yewOZ4VaosSAI6QEtjfZIRajsx2tphl5STKNF474dNj5Gl6WZXQ8HFSpe ncyXeGiUkgpnf5mwoxjXpZhlSVV2/+R456dkd3+jKBkJC5fpjgyquw6zLkkFnYjp sqjzBzDGCdSWowUnEhPwJQ4y8clXoxR5SSdFtT7TpbpY0NMQn94gTBqr63cNOar6 idymJIHMxGc3RKvKzmly/K3WmL5RWtfBDyWOXNvWGDsQLDvgalKbPjgSsMVmkTI2 ofCmKLmvM3kyisXRVaNtsUKWbHuEXcmGRaAN42aLAbn8M42hR6LgxrLRnb/oezmz uOFtymNWtxIKTeNtmfa1m6yaZAgeAENyvKPBxU8vhDMJocn6wCzlcFbI6ntNBFO5 HiN1mbThkDbMGHAo5hIl4737mfmaz3cyEjyXAyHFvVizIEK7RNeNRwvURLte0EsV lNn96S32HRBRO9WTOuPJSG2E6K9c6ByBPDWG0z7LQCtOtL7UiyM=

Hi!

On 12/12/21 10:15, Efraim Flashner wrote:

I ran into the issue on my 32-bit powerpc:

[ 92.119397] unattended-upgr[627]: illegal instruction (4) at ed78a00 nip ed78a00 lr ed789f8 code 1 in libffi.so.8.1.0[ed76000+9000]
[ 92.119499] unattended-upgr[627]: code: 83e1001c 38210020 7c0803a6 4e800020 3d205858 38800000 61295858 387f01e8
[ 92.119516] unattended-upgr[627]: code: 913f0000 48004c3d 393f0014 7fa3eb78 <7c004eee> 393f01e4 7c004fae 48004b55

(ins)efraim@g4:~$ apt-cache policy libffi8
libffi8:
Installed: 3.4.2-3
Candidate: 3.4.2-3
Version table:
*** 3.4.2-3 500
500 http://deb.debian.org/debian-ports sid/main powerpc Packages
100 /var/lib/dpkg/status

I haven't dug into it at all yet.

I forgot to upload the manually built package for 32-bit powerpc which I have done
now. The fixed package should be available on the FTP servers within the next six
hours.

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)

Hello Adrian


John Paul Adrian Glaubitz wrote:

I forgot to upload the manually built package for 32-bit powerpc which I have done
now. The fixed package should be available on the FTP servers within the next six
hours.

The issue was indeed on 32bit PPC as Efraim mentioned.
Thank you for the manual upload, verified and works now, everything in
the green!

Wonderful

Riccardo

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