Description of problem:
Perl on Fedora 32 bit platforms uses 32 bit ints, and on 64 bit
platforms uses 64 bit ints.
This causes some problems when we express size-in-bytes in some
programs -- it is easy for these kind of programs to work fine on
the common 64 bit platform, but to fail to work in bad ways (rounding
errors or overflows) on 32 bit. Since 32 bit is comparatively rare,
these bugs can go unnoticed. An example of a program that will fail
like this is: http://git.annexia.org/?p=import-to-ovirt.git;a=tree
Also, Debian (since Wheezy) has enabled this option, so by making
this change we would be consistent with Debian & Ubuntu.
Some pros and cons described here:
There is also interaction with another option (-Duselongdouble).
Version-Release number of selected component (if applicable):
Of course this is an ABI break, so could only be done when we
are doing a Perl mass rebuild.
I don't know what your script does. It probably bails out when you pushes a large file size into @virtual_sizes.
I have no problem with enabling use64bitint when upgrading to next perl 5.24 in Fedora 25. (Although I'm not aware that i686 has SISD instructions for 64-bit arithmetics. Isn't there a performance penalty with loading and storing integers compounding of two registers?)
I do not want to enable uselongdouble. It has many issues and is often broken.
We will have to do some benchmarks.
For the mean time, you can use Big::Int or bigint, for occasional math.
I meant to add a link to the discussion on devel list. You
may not have seen it because it had a subject line that was
nothing to do with Perl.
Another program we used to have that was broken on 32 bit Perl was:
This program does a bunch of calculations involving partition sizes
in bytes, and float is no use because the calculations don't work
if the least significant bits get truncated.
I eventually rewrote it in a different programming language to get
Issues with uselongdouble:
perl-5.24.0 is built with 64-bit integers everywhere. Floats are still 32-bit on 32-bit platforms due to unresolved issues listed in the previous comment.
This feature is not enabled as tested with perl-5.24.0-379.fc25.i686:
# rpm -q perl
[root@ibm-x3650m4-01-vm-06 ~]# perl -V |grep use64bitint
config_args='-des -Doptimize=none -Dccflags=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Dldflags=-Wl,-z,relro -Dccdlflags=-Wl,--enable-new-dtags -Wl,-z,relro -Dlddlflags=-shared -Wl,-z,relro -Dshrpdir=/usr/lib -DDEBUGGING=-g -Dversion=5.24.0 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib/perl5 -Dvendorarch=/usr/lib/perl5/vendor_perl -Darchname=i386-linux-thread-multi -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize -Duse64bitint1'
use64bitint=undef, use64bitall=undef, uselongdouble=undef
This is because of a typo in the spec file. The "-Duse64bitint1" should be "-Duse64bitint".
As far as I can tell, this is still an issue with current rawhide. At least the spec still has the stray '1'.
Is there any hope of fixing this in F26? I have something that's blocked on 32-bit machines because of lack of unpack("Q>"). I've asked upstream to change their code to not use the quad types in unpack but I'm not sure that they will, and while I've read that there are workarounds I'm not sufficiently well-versed in Perl to try to implement them.
(In reply to Jason Tibbitts from comment #7)
> As far as I can tell, this is still an issue with current rawhide. At least
> the spec still has the stray '1'.
> Is there any hope of fixing this in F26? I have something that's blocked on
> 32-bit machines because of lack of unpack("Q>"). I've asked upstream to
> change their code to not use the quad types in unpack but I'm not sure that
> they will, and while I've read that there are workarounds I'm not
> sufficiently well-versed in Perl to try to implement them.
Enabling the feature requires a mass rebuild (at least of Perl
packages), so it seems unlikely it can be enabled for F26 at
this point. Later Fedora is still worthwhile though.
This will be fixed in F27 only. The features changes ABI.
perl-5.26.0 is built with 64-bit integers everywhere. Floats are still 32-bit on 32-bit platforms.