Is -m32 necessary?
#57
Comments
|
@miguelsousa For this issue #48, I think whether we use |
|
The problem is that there is not just one comparison issue to fix. There is a lot of FDK code which assumes an 'int' is no more than 4 bytes - remember, most of dates from the 1990's. It will take a large effort to fix this. Maybe only one or two man-days to find as much as possible by code inspection, but I'd expect to need a man-week or two of testing and fixing. However, I agree we should leave this open an issue to fix. - just noting that it is not a trivial issue to fix. |
|
I think |
@readroberts any progress on this |
|
Maybe you could create a new branch called "64bit" or something like that, in which to start carrying out the work and where others can contribute patches? that could eventually be merged back into master once it's done. |
|
Is there any unit test for afdko? I think it shall have some test cases before doing the 64-bit migration. |
…issues with 64-bit arch When compiling on 64-bit without `-m32` flag, `sizeof(long)` can be 8 instead of 4. The `long` type is used in several type definitions for the `Fixed` data type. However, the latter is defined in the OpenType spec as a 32-bit number, hence of size 4. Similarly, `unsigned long` is used here to define `LOffset`, but the OpenType spec defines `ULONG` as a 32 bit unsigned number. See adobe-type-tools#57. ```diff +#include <stdint.h> -typedef long Fixed; +typedef int32_t Fixed; -typedef long cffFixed; +typedef int32_t cffFixed; -typedef long hotFixed; +typedef int32_t hotFixed; -typedef unsigned long LOffset; +typedef uint32_t LOffset; ``` Files changed: makeotf_lib/api/cffread.h makeotf_lib/api/hotconv.h makeotf_lib/source/cffread/cffread.c makeotf_lib/source/hotconv/common.h
|
I am ready to drop support for 32-bit systems, and build the AFDKO only for 64 bit systems. I just made a new branch '64bit', and would be very happy to have anyone contribute to this work. The AFDKO does not have a test harness. That has been on my task list for some years. What I use is a set of Adobe fonts: I run a script that applies the AFDKO tools to the fonts, and compares the output with the last set. This marginally adequate solution has worked well enough that building a real test harness hasn't yet made it to the top of the task list. I hope to get to it next year. |
|
Thank you, Read! I'll send out my patches to the new 64bit branch once they are ready. |
|
+1 . I am hoping to scavenging some of the CFF type 2 cstr code into a shared library/ dylib / dll to add to improve CFF support in Font Validator ( HinTak/Font-Validator#13 ) |
|
I do something like this: to feed every *.otf and *.otc and *.ttf and *.ttc to FontVal for testing. That's about 3000 of those, on Fedora Linux - and depends on what those Don't know how many of them are ot[cf]'s, if that's important at all. But you could perhaps do the same thing to look for bugs with -m32. |
|
Thanks for the advice. |
|
Hi, autohintexe seems to be still compiled as a ELF 32-bit LSB executable under 64-bit Ubuntu 18.04 LTS. I checked the latest source codes and found that by 'find . -name "*" | xargs grep -n m32 2> /dev/null' under afdko/c. |
|
@derwind |
|
@derwind Here's the repo for |
|
@miguelsousa @cjchapman Thank you for your explanation! I understand the situation. |
Hi,
I tried to build afdko in 64-bit Linux machine, but due to
-m32flag, the ELF binary is for 32-bits. I wonder, is this flag-m32necessary? Can I build an afdko for 64-bits system only?The text was updated successfully, but these errors were encountered: