Skip Menu |
Report information
Id: 124326
Status: open
Priority: 0/
Queue: perl5

Owner: dom <dom [at] earth.li>
Requestors: helmut [at] subdivi.de
ntyni [at] debian.org
Cc: alex.muntada <alexm [at] cpan.org>
AdminCc:

Operating System: (no value)
PatchStatus: HasPatch
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



To: perlbug [...] perl.org
Date: Fri, 17 Apr 2015 22:45:23 +0300
From: Niko Tyni <ntyni [...] debian.org>
Subject: [PATCH] Configure: Probe intsize with a compile-only test
Download (untitled) / with headers
text/plain 1.5k
Forwarding this report by Helmut Grohne from <https://bugs.debian.org/775940>: A major issue with cross building perl is that it tries to run host arch code during configure. In quite a few cases this is completely unnecessary. Consider its check for sizeof(int) for instance. As we know from autotools, sizeof values can be determined by bisecting using compile-only tests. I am therefore attaching a patch that turns the compile&run test for sizeof(int) into a compile-only test. Practically this means that people who wish to cross build perl no longer need to feed the value of intsize. Of course, this is just a drop in the bucket as there still are longsize, shortsize and many more. What I am seeking here is the preferred method to fix all of them. So rather than submitting a large patch pile against a possibly autogenerated file, I am submitting an incremental improvement to observe the processes. The patch is for 5.20.1 but it applies to current bleadperl with some fuzz. I've tried it out on i386 and amd64 (aka. x86_64), and it correctly determines intsize=4 there but outputs compiler messages like Checking to see how big your integers are... try.c: In function ‘main’: try.c:7:13: error: size of array ‘test’ is negative static int test[1 - 2 * (sizeof(int) >= 1)]; ^ I assume that's trivially fixable. If somebody could please add Helmut Grohne <helmut@subdivi.de> to the watchlist of this ticket, that would probably help discussion by removing me as a middle-man. Many thanks for your work on Perl, -- Niko Tyni ntyni@debian.org

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 266b
I'd like to discuss this once 5.22 has been released. One of the reasons is that smoke-me branches are not covered by the "weird" OS's that this approach would affect, whereas core-smokes do. I'll contact the maintainer of upriver meta/dist to acquire his opinion.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 207b
On Tue May 05 01:27:47 2015, hmbrand wrote: Show quoted text
> I'd like to discuss this once 5.22 has been released.
See: https://rt.perl.org/Ticket/Display.html?id=125096#txn-1347825 which seems to belong to this ticket.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 439b
On Tue May 05 01:27:47 2015, hmbrand wrote: Show quoted text
> I'd like to discuss this once 5.22 has been released. >
Which occurred today! Show quoted text
> One of the reasons is that smoke-me branches are not covered by the > "weird" OS's that this approach would affect, whereas core-smokes do. > > I'll contact the maintainer of upriver meta/dist to acquire his > opinion.
[Tux] How should we proceed? Thank you very much. -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
The answer from the author of dist/meta: --8<--- The current dist (SVN version, not yet found the time / inclination to migrate to git) has switched to compile-time tests whenever possible since 2008. In particular, the current intsize.U unit uses "static asserts" to detect through compile-time errors whether an assertion holds. This allows to compute the size of all types via compile tests, without having to run anything. Even IEEE float endianness is now determined without running a program. No static assert here however: look at d_ieee754.U. The rationale for moving out of run-tests is that it prevents cross-compilation to occur. But when you cross-compile, you always have a compiler handy... Since at some point I had to cross-compile gtk-gnutella with MinGW, I had to move away from run-tests as much as possible! -->8--- So the answer is yes, but this will take way more time than I currently can free: it involves matching every single unit that we (at perl5) use against the current checkout of meta/dist' keeping in mind that we might have diverged from the original path just for perl. The bus factor for this refactor is 1. I have done some one-to-one explanations of the process in the past, but it never lead to more people working on this code.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Tue Jun 02 08:08:24 2015, hmbrand wrote: Show quoted text
> The answer from the author of dist/meta: > > --8<--- > The current dist (SVN version, not yet found the time / inclination > to migrate to git) has switched to compile-time tests whenever > possible since 2008. > > In particular, the current intsize.U unit uses "static asserts" > to detect through compile-time errors whether an assertion holds. > This allows to compute the size of all types via compile tests, > without having to run anything. > > Even IEEE float endianness is now determined without running a > program. > No static assert here however: look at d_ieee754.U. > > The rationale for moving out of run-tests is that it prevents > cross-compilation to occur. But when you cross-compile, you > always have a compiler handy... Since at some point I had to > cross-compile gtk-gnutella with MinGW, I had to move away from > run-tests as much as possible! > -->8--- > > So the answer is yes, but this will take way more time than I > currently can free: it involves matching every single unit that we (at > perl5) use against the current checkout of meta/dist' keeping in mind > that we might have diverged from the original path just for perl. > > The bus factor for this refactor is 1. > > I have done some one-to-one explanations of the process in the past, > but it never lead to more people working on this code.
Hello, Thanks for this explanation which is understandable if unfortunate. I wonder if anything might have changed here since your last update? We're revisiting patching Configure directly in Debian again, as it would (eventually) make cross-building easier, but this is indeed makework if the real fix is tractable. Thanks, Dominic.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org