[Bug 734954] (lt-Gst-1.0:19423): GLib-ERROR **: ../../glib/gmem.c:353: overflow allocating 1701079383*4 bytes

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=734954

--- Comment #23 from Aurelien Larcher <aurelien.larcher at gmail.com> ---
(In reply to Tim-Philipp Müller from comment #22)
> No, but you must pass --build=i686-pc-linux-gnu for autotools to use/detect
> the right HOST_CPU. If it is omitted, and just -m32 or such is passed, then
> what Aurelien describes may happen. The patch Aurelien references is not
> right and should not be required if cross-compile is done correctly.

This is maybe true for Linux but Solaris/illumos has a different handling of
architectures (similar to IRIX) which actually predates Linux's 64-bit support.

On Solaris/illumos the host architecture may support different ISAs (i386 and
amd64) and each ISA can have extensions (remember also that on IRIX up to 3
ISAs would co-exist).
Tools default to the least-common denominator for each architecture: that's why
for instance gcc defaults to 32-bit on 64-bit capable x86.

>From the beginning amd64 has been seen as an extension of i386 on 64-bit
capable machines, and not as a totally different architecture.
The reason is the care for backward-compatibility: providing 32- and 64-bit
libs and userland is a natural continuity if the 64-bit ISA is seen as an
extension, and not retrofitted with latter addition of "*-lib32" and
cross-compilation.

In this case, relying on HOST_CPU is incorrect because the host cpu being
assumed to be possibly both 32- and 64-bit capable, the switch happens with
compilation flags.

I guess it is a matter of definition.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.