Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 06.11.21 10:49, Helmut Grohne wrote:
> I confirm. Mystery finally solved. The next upstream release shall close
> this bug.

So, that powerpc problem with computing long double epsilon was a false
alarm, then?

If you could confirm that, I'ld close this, spin a release, and be
happy.  ;-)

  -richy.
-- 
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Control: tags -1 + fixed-upstream - patch

On Sat, Nov 06, 2021 at 02:27:07AM +0100, Richard B. Kreckel wrote:
> Yes, I can. There seems to be a misunderstanding.
> 
> This hang creating intparam.h is the known issue you reported and that
> should be fixed upstream.
> 
> Sorry, the Debian package version 1.3.6-4 is not fixed yet.

Thank you. Now that you put it so clearly, I think all the pieces of the
puzzle fit together neatly. All our observations make perfect sense now.

> Could you, please, try checking out cln from
> https://www.ginac.de/CLN/cln.git/ and run
> $ ./autogen.sh
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared

I confirm. Mystery finally solved. The next upstream release shall close
this bug.

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 05.11.21 23:28, Helmut Grohne wrote:
> I created a fresh unstable chroot containing only essential and then ran
> the following commands inside:
> 
> # dpkg --add-architecture ppc64el
> # apt-get update
> # apt-get install g++-powerpc64le-linux-gnu make file libgmp-dev:ppc64el
> $ apt-get source cln
> $ cd cln-*
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> 
> It hangs. The last line of output is:
> 
> creating include/cln/intparam.h
> 
> I deliberately used precisely your configure invocation here. As you can
> see, I cannot reproduce your success. Can you reproduce my failure this
> way?
Yes, I can. There seems to be a misunderstanding.

This hang creating intparam.h is the known issue you reported and that
should be fixed upstream.

Sorry, the Debian package version 1.3.6-4 is not fixed yet.

Could you, please, try checking out cln from
https://www.ginac.de/CLN/cln.git/ and run
$ ./autogen.sh
$ ./configure --host=powerpc64le-linux-gnu --disable-shared

The question I am trying to get an answer for is if this really still
hangs in CL_FLOATPARAM_CROSS.

  -richy.
-- 
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi Richard,

On Fri, Nov 05, 2021 at 11:00:17PM +0100, Richard B. Kreckel wrote:
> So I uninstalled it. It still compiles and I can still run the tests.

That makes things interesting. Let us pin down as much as we can to
figure out the difference.

I created a fresh unstable chroot containing only essential and then ran
the following commands inside:

# dpkg --add-architecture ppc64el
# apt-get update
# apt-get install g++-powerpc64le-linux-gnu make file libgmp-dev:ppc64el
$ apt-get source cln
$ cd cln-*
$ ./configure --host=powerpc64le-linux-gnu --disable-shared

It hangs. The last line of output is:

creating include/cln/intparam.h

I deliberately used precisely your configure invocation here. As you can
see, I cannot reproduce your success. Can you reproduce my failure this
way?

If not, can you maybe try building the cln source package from unstable
for ppc64el using sbuild or pbuilder?

> > The last attempt for ppc64el is a bit dated already:
> > http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
> > I scheduled a new attempt now.

That failed as expected:
http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20211105143826.log

> > For all other architectures, we see a new issue:
> > 
> > ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit 
> > into an intptr_t!!"
> >26 | #error "Type char * does not fit into an intptr_t!!"
> >   |  ^
> > 
> > That even happens for combinations of 64bit architectures. I see that
> > stdint.h is now included, so I don't understand why it fails like that.
> 
> I don't understand either. That check should really work.
> 
> Obviously, I cannot reproduce that either.
> 
> Since when do we get this?

You can easily tell from looking at http://crossqa.debian.net/src/cln:
Since the 1.3.6-1 upload.

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 05.11.21 15:41, Helmut Grohne wrote:
> On Fri, Nov 05, 2021 at 10:32:59AM +0100, Richard B. Kreckel wrote:
> I vaguely suspect that you do have qemu-user-binfmt installed and that
> it enables running foreign binaries and changes the way configure
> behaves. Does that match reality?

Indeed, qemu-user-binfmt was installed.

So I uninstalled it. It still compiles and I can still run the tests.

> The last attempt for ppc64el is a bit dated already:
> http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
> I scheduled a new attempt now.
> 
> For all other architectures, we see a new issue:
> 
> ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into 
> an intptr_t!!"
>26 | #error "Type char * does not fit into an intptr_t!!"
>   |  ^
> 
> That even happens for combinations of 64bit architectures. I see that
> stdint.h is now included, so I don't understand why it fails like that.

I don't understand either. That check should really work.

Obviously, I cannot reproduce that either.

Since when do we get this?

> Does that help you with reproducing the failures I see?

Unfortunately, no.

  -richy.
-- 
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi Richard,

On Fri, Nov 05, 2021 at 10:32:59AM +0100, Richard B. Kreckel wrote:
> How can I reproduce this?

Thank you for looking into the issue.

> On my bullseye setup, this works:
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> $ make
> $ qemu-ppc64le -L /usr/powerpc64le-linux-gnu ./tests/exam
> Tests passed.

I do wonder how I can reproduce this. :)

> It surely produces the expected floatparam.h file, with
> long_double_mant_bits set to 106.

You can find complete cross build logs at
http://crossqa.debian.net/src/cln. There you can find complete configure
invocations and the precise packages that were used for performing the
build.

I vaguely suspect that you do have qemu-user-binfmt installed and that
it enables running foreign binaries and changes the way configure
behaves. Does that match reality?

The last attempt for ppc64el is a bit dated already:
http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
I scheduled a new attempt now.

For all other architectures, we see a new issue:

../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into an 
intptr_t!!"
   26 | #error "Type char * does not fit into an intptr_t!!"
  |  ^

That even happens for combinations of 64bit architectures. I see that
stdint.h is now included, so I don't understand why it fails like that.

Does that help you with reproducing the failures I see?

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 05.11.21 10:32, Richard B. Kreckel wrote:
> On my bullseye setup, this works:
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> $ make
> $ qemu-ppc64le -L /usr/powerpc64le-linux-gnu ./tests/exam
> Tests passed.

It was on a bookworm/unstable setup, actually.
(I don't see how that would matter.)

  -richy.
-- 
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 28.08.21 13:53, Helmut Grohne wrote:
> The issue is with the detection of the long double epsilon on powerpc
> architectures. m4/floatparam.m4' macro CL_FLOATPARAM_CROSS attempts to
> deduce the minimal value that can be added to 1 using compile time
> bisection. That works, because gcc does constant folding of floating
> point numbers, except when it does not not powerpc architectures. There
> is a long standing gcc bug
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779.
> 
> Would there be any chance to use gcc constants such as LDBL_EPSILON for
> this case (even opportunistically)?
> 
> In any case, the current implementation is very bad, because the while
> loop never finishes as every compilation attempt fails on the supposedly
> non-constant expression. At minimum, there should be a bound on the
> number of iterations.

How can I reproduce this?

On my bullseye setup, this works:
$ ./configure --host=powerpc64le-linux-gnu --disable-shared
$ make
$ qemu-ppc64le -L /usr/powerpc64le-linux-gnu ./tests/exam
Tests passed.

It surely produces the expected floatparam.h file, with
long_double_mant_bits set to 106.

  -richy.
-- 
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi,

On Mon, Oct 19, 2020 at 11:11:40AM +0200, Richard B. Kreckel wrote:
> Okay, all that has just been fixed upstream now.

I contend that the cross build still loops for ppc64el. It kinda feels
like a different issue though. Should we close this one and open a new
one or retitle?

The issue is with the detection of the long double epsilon on powerpc
architectures. m4/floatparam.m4' macro CL_FLOATPARAM_CROSS attempts to
deduce the minimal value that can be added to 1 using compile time
bisection. That works, because gcc does constant folding of floating
point numbers, except when it does not not powerpc architectures. There
is a long standing gcc bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779.

Would there be any chance to use gcc constants such as LDBL_EPSILON for
this case (even opportunistically)?

In any case, the current implementation is very bad, because the while
loop never finishes as every compilation attempt fails on the supposedly
non-constant expression. At minimum, there should be a bound on the
number of iterations.

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 12.10.20 20:49, Helmut Grohne wrote:

I strongly suggest that you do not proxy builds through me. The latency
is much higher than doing it yourself. The primary goal of cross builds
is that you can build for anything on your box instead of having to own
the target box. All you need to do is pass --host to sbuild or
--host-arch to pbuilder.

Nevertheless, I attempted applying your box and built for arm64 and
ppc64el. With the patch, it passes the build for arm64, but ppc64el
still hangs in configure.


Okay, all that has just been fixed upstream now.

  -richy.
--
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi,

On Sun, Oct 11, 2020 at 11:04:05PM +0200, Richard B. Kreckel wrote:
> > Before I dig into this, could you, please, try applying the attached patch
> and check if it works?

I strongly suggest that you do not proxy builds through me. The latency
is much higher than doing it yourself. The primary goal of cross builds
is that you can build for anything on your box instead of having to own
the target box. All you need to do is pass --host to sbuild or
--host-arch to pbuilder.

Nevertheless, I attempted applying your box and built for arm64 and
ppc64el. With the patch, it passes the build for arm64, but ppc64el
still hangs in configure.

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 11.10.20 19:28, Helmut Grohne wrote:

If you are interested in figuring out why this happens, all the better,
I guess you should pass --anything-failed-commands=%SBUILD_SHELL to
sbuild and examine config.log.


Before I dig into this, could you, please, try applying the attached 
patch and check if it works?


(It's a little bit a stab in the dark, just reverting the last changes 
made there. After all, it should've worked before.)


  -richy.
--
Richard B. Kreckel

diff --git a/m4/intparam.m4 b/m4/intparam.m4
index 3c990d7..7d81424 100644
--- a/m4/intparam.m4
+++ b/m4/intparam.m4
@@ -113,7 +113,7 @@ AC_DEFUN([CL_INTPARAM_CROSS],
 echo "#error \"Integer types long long and unsigned long long have different sizes!!\""
   fi
 fi
-AC_TRY_COMPILE([#include ], [static_assert(sizeof(char*) <= sizeof(intptr_t), "");],
+AC_TRY_COMPILE([#include ], [typedef int verify[2*(sizeof(char*)<=sizeof (intptr_t))-1];],
   [], [echo "#error \"Type char * does not fit into an intptr_t!!\""])
 _AC_COMPUTE_INT([sizeof (char *)], [pointer_size])
 pointer_bitsize=`expr $pointer_size '*' $char_bitsize`
@@ -290,7 +290,7 @@ AC_DEFUN([CL_INTPARAM_ALIGNOF],
 #else
 # define alignof(type)  offsetof (struct { char slot1; type slot2; }, slot2)
 #endif
-], [static_assert(alignof($1) == $n, "");],
+], [typedef int verify[2*(alignof($1) == $n) - 1];],
   [$2=$n; break;]
   [if test $n = 0; then $2=; break; fi])
 n=`expr $n '*' 2`

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

On Sun, Oct 11, 2020 at 12:27:03PM +0200, Richard B. Kreckel wrote:
> Thank you! Your patch has been upstreamed.

Great! This is not urgent from my pov, just close the Debian bug with
the new upstream upload.

> > I fear this is not the only issue. For instance on ppc64el, the build
> > times out during configure. I haven't figured out why yet. Can you just
> > fix the missing include and close this bug when doing so?
> 
> I would love to know at which point configure gets stuck.

You can get an overview at http://crossqa.debian.net/src/cln. The
failure mode is architecture-dependent:

This bug:
 * arm64
 * armel
 * armhf
 * mips64el
 * mipsel
 * s390x

Build timeout while generating intparam.h on ppc64el:
 * http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20200107193158.log
 * http://crossqa.debian.net/build/cln_1.3.6-3_ppc64el_20200106155133.log
 * http://crossqa.debian.net/build/cln_1.3.6-1_ppc64el_20191207104527.log

If you are interested in figuring out why this happens, all the better,
I guess you should pass --anything-failed-commands=%SBUILD_SHELL to
sbuild and examine config.log.

Helmut

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

On 10.10.20 07:04, Helmut Grohne wrote:

Source: cln
Version: 1.3.6-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cln fails to cross build from source, because it checks for the size of
intptr_t without including . It thus fails detecting a size
and errors out. Please add the required include. I'm attaching a patch
for that.


Thank you! Your patch has been upstreamed.


I fear this is not the only issue. For instance on ppc64el, the build
times out during configure. I haven't figured out why yet. Can you just
fix the missing include and close this bug when doing so?


I would love to know at which point configure gets stuck.

  -richy.
--
Richard B. Kreckel

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Source: cln
Version: 1.3.6-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cln fails to cross build from source, because it checks for the size of
intptr_t without including . It thus fails detecting a size
and errors out. Please add the required include. I'm attaching a patch
for that.

I fear this is not the only issue. For instance on ppc64el, the build
times out during configure. I haven't figured out why yet. Can you just
fix the missing include and close this bug when doing so?

Helmut
--- cln-1.3.6.orig/m4/intparam.m4
+++ cln-1.3.6/m4/intparam.m4
@@ -113,7 +113,7 @@
 echo "#error \"Integer types long long and unsigned long long have different sizes!!\""
   fi
 fi
-AC_TRY_COMPILE([], [static_assert(sizeof(char*) <= sizeof(intptr_t), "");],
+AC_TRY_COMPILE([#include ], [static_assert(sizeof(char*) <= sizeof(intptr_t), "");],
   [], [echo "#error \"Type char * does not fit into an intptr_t!!\""])
 _AC_COMPUTE_INT([sizeof (char *)], [pointer_size])
 pointer_bitsize=`expr $pointer_size '*' $char_bitsize`