Date: Fri, 2 Jan 2009 17:44:39 +0100 From: Anton Berezin <tobez@tobez.org> To: Fernan Aguero <fernan.aguero@gmail.com> Cc: freebsd-perl@freebsd.org Subject: Re: Storable byteorder incompatibilities in different FreeBSD installations Message-ID: <20090102164439.GF40649@heechee.tobez.org> In-Reply-To: <520894aa0901020758o79bb1233teee539f6d599d10a@mail.gmail.com> References: <520894aa0901020758o79bb1233teee539f6d599d10a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 02, 2009 at 01:58:06PM -0200, Fernan Aguero wrote: > I've been bitten by binary incompatibilitiess (bytorder, and/or byte > sizes of ints, longs, and whatnot) between two perl installations > (both on FreeBSD, using latest perl5.8 from ports). [...] > Binary incompatibilities when reading the Storable binary data have > been observed in the past when running the web application from Linux > boxes (Ubuntu, i386 or amd64). > So why is it that building Perl outside of the ports system makes the > test program report '1234' which is what I would expect from an i386 > box, while it gives '12345678' when running from within the ports > system? Why this unusual byteorder? This is because of PERL_64BITINT (aka -Duse64bitint) is the default with the port. > And now for a pragmatic and urgent question: > iv) how can I use the ports system to build a Perl in different FBSD > boxes that would result in the same binary configuration (byteorder, > shortsize, intsize, etc.) to guarantee it would produce compatible > (i.e. readable from other FBSD boxes) dumps of Perl data structures? Uncheck PERL_64BITINT in the configuration dialog. (make rmconfig first) Apart from that, do you actually use "nstore" variants of Storable functions? If you use it consistently in you application, you might find out that the problem disappears, and it would not matter what platform you use. Cheers, \Anton. -- There is no beauty in entropy. -- Eliezer Yudkowsky
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090102164439.GF40649>