cln fails to cross build from source, because it checks for the size of intptr_t without including <stdint.h>. 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
Thank you! Your patch has been upstreamed. I would love to know at which point configure gets stuck. -richy.
Great! This is not urgent from my pov, just close the Debian bug with the new upstream upload. 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
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.
Hi, 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
Okay, all that has just been fixed upstream now. -richy.
Hi, 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
Hi Helmut, 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.
It was on a bookworm/unstable setup, actually. (I don't see how that would matter.) -richy.
Hi Richard, Thank you for looking into the issue. I do wonder how I can reproduce this. :) 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
Hi Helmut, Indeed, qemu-user-binfmt was installed. So I uninstalled it. It still compiles and I can still run the tests. I don't understand either. That check should really work. Obviously, I cannot reproduce that either. Since when do we get this? Unfortunately, no. -richy.
Hi Richard, 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? http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20211105143826.log Since the 1.3.6-1 upload. Helmut
Hi Helmut, 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.
Control: tags -1 + fixed-upstream - patch 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. I confirm. Mystery finally solved. The next upstream release shall close this bug. Helmut
Hi Helmut, 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.