freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] Bug#94041: Freetype (either version) not 64-bit clean


From: Tom Kacvinsky
Subject: Re: [Devel] Bug#94041: Freetype (either version) not 64-bit clean
Date: Sun, 15 Apr 2001 15:09:43 -0400 (EDT)

Hi Anthony,

I would like to see backtraces (from gdb) of the core dumps the Debian
developers are seeing.  I myslef have seen plenty of core dumps with Tru64 UNIX
(which David Turned and I fixed), but I don't have access to Debian running on
an Alpha box, so I can't help with the particular issues on that platform.

Note well: whatever fixes I come up with will be for FreeType 2.x and not
FreeType 1.x.  I am not familiar enough with 1.x's code base to feel confident
with any changes I would make for that code base.

In the meantime, I will be working on the 64 bit long issue.  Please note that
on Alphas, typecasting won't always work (one can still get unaligned accesses),
and even if certain variables are made to be 32 bits wide, pointers will
*always* be 64 bits wide (at least with Compaq's C compiler).

I can't speak for the Windows 64 bit compilers.

Regards,

Tom

On Sun, 15 Apr 2001, Anthony Fok wrote:

> Hello all,
>
> I just received a _critical_ bug report on FreeType
> from a fellow Debian developer.  It does look quite serious
> because neither FreeType 1 nor FreeType 2 works properly
> on a 64-bit platform like Alpha, Sparc64 and the upcoming IA64.
>
> So yes, please do try to fix it to make FreeType truly
> a universal font engine.
>
> Thanks,
>
> Anthony
>
> ----- Forwarded message from "Christopher C. Chimelis" <address@hidden> -----
>
> Date: Sun, 15 Apr 2001 05:18:04 -0400 (EDT)
> From: "Christopher C. Chimelis" <address@hidden>
> Subject: Bug#94041: Freetype (either version) not 64-bit clean
> To: address@hidden
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
> Package: freetype
> Version: 2.0.2.20010412-1
> Severity: critical
>
> All versions of freetype are not 64-bit clean.  The headers are littered
> with things like:
>     TT_ULong   ulUnicodeRange1;        /* Bits 0-31   */
>     TT_ULong   ulUnicodeRange2;        /* Bits 32-63  */
>     TT_ULong   ulUnicodeRange3;        /* Bits 64-95  */
>     TT_ULong   ulUnicodeRange4;        /* Bits 96-127 */
>
> On Alpha (also IA64 and possibly sparc64), ULong=64bit unsigned
> long.  This causes problems when running some things, such as ttfbanner
> from freetype-tools.  Here's a sample from Alpha...the segfault is because
> of 64-bit issues:
>       address@hidden:
>       ~ > ttfbanner -p 8 ./ARIAL.TTF test
>       Segmentation fault
>
> This has been brought up with upstream by myself and one other Tru64
> porter, but at the time, they denied that it was a problem despite
> numerous examples of segfaults and problems.
>
> This has been a known issue for quite some time, but I attempted to make a
> patch to fix it.  Unfortunately, the source defied all attempts.  If you
> can speak with them and/or make the code NOT assume that longs and
> pointers are not 32-bits, the entire Alpha-Linux world would owe you a
> beer :-P
>
> C
>
>
> ----- End forwarded message -----
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]