Compiling FreeType 2.1.9 with LLVM 1.4

Hi all,

I learned of LLVM a couple of days ago:
<http://groups.google.co.nz/groups?selm=pan.2004.12.18.11.29.33.33249%40consulting.net.nz&gt;
<Sign in - Google Accounts;
(I posted a tail call followup which is missing from the archive)

Jestingly, LLVM developers appear intent upon nothing short of world
domination. Not only have you done an end run around exposing the back end
of the GNU Compiler Collection but you are positioning yourselves to
dominate popular virtual machines architectures (such as the JVM from Sun
and the CLR from Microsoft) by translating their classes to LLVM bytecode.
Suffice to say you know what you're doing and it's currently a well kept
secret :wink:

I suspect GCC may be entering a period of twilight that cannot be solved
by forking (unlike occurred in 1997 with EGCS). The world is waking up to
what Lisp developers have been doing for decades: run time code generation
and compilation. The potentially onerous legal restrictions upon using GCC
as a run time and/or JIT compiler can not be solved by forking. GCC may
remain a static compiler and may increasingly become a legacy component of
build systems.

Putting these long term predictions aside, I have modest goals. I'm
learning C and I want to build portable libraries. LLVM's modification of
GCC so it outputs portable LLVM bytecode is ideal. I'd like to build
FreeType 2 as an LLVM library instead of an ordinary shared object (then
I can link my bytecode and the FreeType 2 library together).

I've built llvm-1.4.tar.gz using the cfrontend-1.4.i686-redhat-linux-gnu.tar.gz
binaries. As I didn't appreciate the registration front end I just googled for
the file names.

My new environment is:

export LLVM_LIB_SEARCH_PATH=/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bytecode-libs
export PATH=/home/adam/t/llvm/Release/bin/:/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/:$PATH
export CC=/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/gcc
export CCC=/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/g++

Here's what occurs when building FreeType 2 with LLVM:

1. Download FreeType 2.1.9:
<The FreeType Project - Browse Files at SourceForge.net;
2. Open Bash shell and set environment variables above. gcc -v is now:

Reading specs from /home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/../lib/gcc/i686-pc-linux-gnu/3.4-llvm/specs
Configured with: /home/vadve/criswell/release/llvm-gcc/configure
--prefix=/mounts/choi/disks/0/localhome/criswell/rel14/cfrontend/x86/llvm-gcc
--disable-threads --disable-nls --disable-shared --enable-languages=c,c++
Thread model: single
gcc version 3.4-llvm 20030924 (experimental)

3. tar -jxvf freetype-2.1.9.tar.bz2
4. cd freetype-2.1.9
5. edit builds/unix/configure to match GCC's build flags:

if test "x$CC" = xgcc; then
  XX_CFLAGS="-Wall"
  XX_ANSIFLAGS="-pedantic -ansi"
else
  case "$host" in
  *-dec-osf*)
    CFLAGS=
    XX_CFLAGS="-std1 -g3"
    XX_ANSIFLAGS=
    ;;
  *)
    XX_CFLAGS=
    XX_ANSIFLAGS=
    ;;
  esac
fi

becomes:

  XX_CFLAGS="-Wall"
  XX_ANSIFLAGS="-pedantic -ansi"

5. ./configure
6. make

Building dies part way through with these messages:

/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/gcc -pedantic -ansi -I/home/adam/t/freetype-2.1.9/objs -I./builds/unix -I/home/adam/t/freetype-2.1.9/include -c -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -I/home/adam/t/freetype-2.1.9/src/sfnt /home/adam/t/freetype-2.1.9/src/sfnt/sfnt.c -o /home/adam/t/freetype-2.1.9/objs/sfnt.o
In file included from /home/adam/t/freetype-2.1.9/src/sfnt/sfnt.c:22:
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c: In function `tt_face_load_generic_header':

/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:597: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:597: error: (near initialization for `header_fields[7].offset')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:597: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:597: error: (near initialization for `header_fields[7]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:598: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:598: error: (near initialization for `header_fields[8].offset')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:598: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:598: error: (near initialization for `header_fields[8]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:599: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:599: error: (near initialization for `header_fields[9].offset')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:599: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:599: error: (near initialization for `header_fields[9]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:600: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:600: error: (near initialization for `header_fields[10].offset')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:600: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:600: error: (near initialization for `header_fields[10]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:601: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:601: error: (near initialization for `header_fields[11]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:602: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:602: error: (near initialization for `header_fields[12]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:603: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:603: error: (near initialization for `header_fields[13]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:604: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:604: error: (near initialization for `header_fields[14]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:605: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:605: error: (near initialization for `header_fields[15]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:606: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:606: error: (near initialization for `header_fields[16]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:607: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:607: error: (near initialization for `header_fields[17]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:608: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:608: error: (near initialization for `header_fields[18]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:609: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:609: error: (near initialization for `header_fields[19]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:610: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:610: error: (near initialization for `header_fields[20]')
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c: In function `tt_face_load_metrics_header':

/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:986: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:986: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:987: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:987: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:988: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:988: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:989: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:989: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c: In function `tt_face_load_os2':

/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1319: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1319: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1320: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1320: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1321: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1321: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1322: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1322: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1323: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1323: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1324: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1324: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1325: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1325: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1326: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1326: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1327: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1327: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1328: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1328: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1333: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1333: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1334: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1334: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1335: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1335: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1336: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:1336: warning: initializer element is not computable at load time
In file included from /home/adam/t/freetype-2.1.9/src/sfnt/sfnt.c:28:
/home/adam/t/freetype-2.1.9/src/sfnt/ttsbit.c: In function `tt_face_load_sbit_strikes':

/home/adam/t/freetype-2.1.9/src/sfnt/ttsbit.c:421: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttsbit.c:421: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttsbit.c:422: warning: initializer element is not computable at load time
/home/adam/t/freetype-2.1.9/src/sfnt/ttsbit.c:422: warning: initializer element is not computable at load time
make: *** [/home/adam/t/freetype-2.1.9/objs/sfnt.lo] Error 1

Note that when using standard GCC FreeType builds fine:

Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,
objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib
--enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-4)

Many thanks for any build tips. My operating system is Debian GNU/Linux sid/unstable.

If this is too experimental to be expected to work I'll learn how LLVM bc can be
linked with C shared objects instead. I'm currently to the point where I can execute
my own bytecode via lli (or compile it via llc) and produce this output:

$ lli a.out.bc
ERROR: Program used external function 'FT_Init_FreeType' which could not be resolved!
lli((anonymous namespace)::PrintStackTrace()+0x1f)[0x835875f]
/lib/tls/libc.so.6(abort+0x1d2)[0x40135f12]
lli[0x810666b]
Aborted

[This is expected, of course, as I'm attempting to get to the point of linking]

Many thanks,
Adam

LLVM developers intent on world domination? Now that you've uncovered their secret, they'll have to eliminate you, you know :slight_smile:

I don't have a working LLVM system right now (in the middle of building a new FreeBSD system), but I did take a look at the code. The heavy use of macros makes it hard to tell exactly what the compiler is seeing. Could you capture the output of the C preprocessor?

It looks like the front end is having a problem with the expansion of these macros:

#define FT_FIELD_SIZE( f ) \
          (FT_Byte)sizeof ( ((FT_STRUCTURE*)0)->f )

#define FT_FIELD_OFFSET( f ) \
          (FT_UShort)( offsetof( FT_STRUCTURE, f ) )
where "f" is an array element like "xyz[0]". Problem is, LLVM's front end *is* gcc and it works for you when using gcc. But then, you're using gcc 3.3.5 and LLVM uses 3.4. But then (again), I just built Freetype 2.1.7 on FreeBSD using gcc 3.4.2 without problems.

Adam Warner wrote:

Hi all,

Hi Adam,

I learned of LLVM a couple of days ago:
<http://groups.google.co.nz/groups?selm=pan.2004.12.18.11.29.33.33249%40consulting.net.nz&gt;
<Sign in - Google Accounts;
(I posted a tail call followup which is missing from the archive)
Jestingly, LLVM developers appear intent upon nothing short of world
domination. Not only have you done an end run around exposing the back end
of the GNU Compiler Collection but you are positioning yourselves to
dominate popular virtual machines architectures (such as the JVM from Sun
and the CLR from Microsoft) by translating their classes to LLVM bytecode.
Suffice to say you know what you're doing and it's currently a well kept
secret :wink:

Hey, YOU found out! :slight_smile:

I suspect GCC may be entering a period of twilight that cannot be solved
by forking (unlike occurred in 1997 with EGCS). The world is waking up to
what Lisp developers have been doing for decades: run time code generation
and compilation. The potentially onerous legal restrictions upon using GCC
as a run time and/or JIT compiler can not be solved by forking. GCC may
remain a static compiler and may increasingly become a legacy component of
build systems.

Strangely enough, there has been "some" talk between the GCC and LLVM
teams of having GCC using LLVM as a "back end". Nothing's been decided
yet and there's many political/legal/technical hurdles to cross, but
(selfishly) we believe that such a move on GCC's part might breathe some
life back into GCC. That would be a good thing as a *lot* of investment
has gone into making GCC what it is today.

Putting these long term predictions aside, I have modest goals. I'm
learning C and I want to build portable libraries. LLVM's modification of
GCC so it outputs portable LLVM bytecode is ideal. I'd like to build
FreeType 2 as an LLVM library instead of an ordinary shared object (then
I can link my bytecode and the FreeType 2 library together).

Okay.

After a review of the following, it looks like you're seeing a
difference in the GCC 3.4 compiler LLVM is based on and the GCC 3.3.5
compiler that you normally compile FreeType with. I would be interested
to know if FreeType can compile with (regular) GCC 3.4.3

Reid.

I've built llvm-1.4.tar.gz using the cfrontend-1.4.i686-redhat-linux-gnu.tar.gz
binaries. As I didn't appreciate the registration front end I just googled for
the file names.

My new environment is:

export LLVM_LIB_SEARCH_PATH=/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bytecode-libs
export PATH=/home/adam/t/llvm/Release/bin/:/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/:$PATH
export CC=/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/gcc
export CCC=/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/g++

I'm not sure but I think you want CXX there not CCC.

Here's what occurs when building FreeType 2 with LLVM:

1. Download FreeType 2.1.9:
<The FreeType Project - Browse Files at SourceForge.net;
2. Open Bash shell and set environment variables above. gcc -v is now:

Reading specs from /home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/../lib/gcc/i686-pc-linux-gnu/3.4-llvm/specs
Configured with: /home/vadve/criswell/release/llvm-gcc/configure
--prefix=/mounts/choi/disks/0/localhome/criswell/rel14/cfrontend/x86/llvm-gcc
--disable-threads --disable-nls --disable-shared --enable-languages=c,c++
Thread model: single
gcc version 3.4-llvm 20030924 (experimental)

Note that this is "3.4-llvm"

3. tar -jxvf freetype-2.1.9.tar.bz2
4. cd freetype-2.1.9
5. edit builds/unix/configure to match GCC's build flags:

if test "x$CC" = xgcc; then
  XX_CFLAGS="-Wall"
  XX_ANSIFLAGS="-pedantic -ansi"
else
  case "$host" in
  *-dec-osf*)
    CFLAGS=
    XX_CFLAGS="-std1 -g3"
    XX_ANSIFLAGS=
    ;;
  *)
    XX_CFLAGS=
    XX_ANSIFLAGS=
    ;;
  esac
fi

becomes:

  XX_CFLAGS="-Wall"
  XX_ANSIFLAGS="-pedantic -ansi"

Okay, that should be fine.

5. ./configure
6. make

I built FreeType-2.1.9 with LLVM's GCC and it worked fine. However, I
didn't sent any environment variables, configured normally and then made
it with:

CC=/path/to/gcc CXX=/path/to/g++ make

It all compiled just fine. You might want to try the same.

Building dies part way through with these messages:

/home/adam/t/llvm/cfrontend/x86/llvm-gcc/bin/gcc -pedantic -ansi -I/home/adam/t/freetype-2.1.9/objs -I./builds/unix -I/home/adam/t/freetype-2.1.9/include -c -Wall -g -O2 -DFT_CONFIG_OPTION_SYSTEM_ZLIB -DDARWIN_NO_CARBON "-DFT_CONFIG_CONFIG_H=<ftconfig.h>" -I/home/adam/t/freetype-2.1.9/src/sfnt /home/adam/t/freetype-2.1.9/src/sfnt/sfnt.c -o /home/adam/t/freetype-2.1.9/objs/sfnt.o
In file included from /home/adam/t/freetype-2.1.9/src/sfnt/sfnt.c:22:
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c: In function `tt_face_load_generic_header':

/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:597: error: initializer element is not constant
/home/adam/t/freetype-2.1.9/src/sfnt/ttload.c:597: error: (near initialization for `header_fields[7].offset')

.. snip ..

Note that when using standard GCC FreeType builds fine:

Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs

Yes, but LLVM is based on 3.4 not 3.3. GCC 3.4 has *many* improvements
and is much stricter than it used to be.

Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,
objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib
--enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-4)

Many thanks for any build tips. My operating system is Debian GNU/Linux sid/unstable.

"should" be okay. Not many (none?) of us use Debian.

If this is too experimental to be expected to work I'll learn how LLVM bc can be
linked with C shared objects instead.

LLVM can also generate ANSI C code so you can get executables that way
too. Check out the -march option of llc. "llc --help".

I'm currently to the point where I can execute
my own bytecode via lli (or compile it via llc) and produce this output:

Great!

$ lli a.out.bc
ERROR: Program used external function 'FT_Init_FreeType' which could not be resolved!
lli((anonymous namespace)::PrintStackTrace()+0x1f)[0x835875f]
/lib/tls/libc.so.6(abort+0x1d2)[0x40135f12]
lli[0x810666b]
Aborted

[This is expected, of course, as I'm attempting to get to the point of linking]

I suspect if you build as described above, you'll be able to resolve
these link errors :slight_smile:

Reid

Problem is, LLVM uses a version of GCC from CVS, so it's "sorta"
gcc-3.4, but it's not up-to-date on the 3.4 branch, so if GCC parsing
bugs have been fixed, we haven't gotten them all.

If it's C code with no inline assembly that GCC compiles, LLVM should
compile it too. Please file a bug with preprocessed source, and if you
have the time to narrow down the source code to the minimum test case
that fails, we would appreciate it, and it will get the bug fixed that
much faster.

Thanks,

Adam,

I recant my previous message. I built FreeType with GCC not LLVMGCC by
accident (I shoulda checked!). The thing is, FreeType's makefiles don't
respect environment variables. So, I did this:

CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure
make

and was able to reproduce the problem. Not sure what's up with that but
as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its
just 3.4ish. I also concur with him that you should file a bug and
attach the pre-processed source to it. You can get that with the -E flag
to GCC.

Bugs can be reported here: http://llvm.cs.uiuc.edu/bugs/

Reid.

Hi Reid Spencer,

CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure
make

and was able to reproduce the problem. Not sure what's up with that but
as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its
just 3.4ish. I also concur with him that you should file a bug and
attach the pre-processed source to it. You can get that with the -E flag
to GCC.

Many thanks for everyone's wonderful replies.

I added the -E flag to the build options. Are the preprocessed sources the
.o files that now look something like this:

# 1 "/home/adam/t/t5/freetype-2.1.9/src/sfnt/sfnt.c"
# 1 "/home/adam/t/t5/freetype-2.1.9//"
# 1 "/home/adam/t/t5/freetype-2.1.9/src/sfnt/sfnt.c"
# 1 "<built-in>"
# 1 "<command line>"
...
typedef int _G_int16_t __attribute__ ((__mode__ (__HI__)));
typedef int _G_int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned int _G_uint16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int _G_uint32_t __attribute__ ((__mode__ (__SI__)));
...

...because there's 4.8MB of them and I'd first like to confirm this is
what I should be attaching. I'm sorry but at this stage I don't have the
capabilities to narrow down the FreeType source code to a minimum test
case (unless the FreeType source code happens to looks uncannily like the
C version of Hello, World!)

Regards,
Adam

It's way too big to send to this mailing list anyway. E-mail it to me directly and I'll see what I can do with it. I'm rebuilding LLVM on FreeBSD right now and it will be a good test :slight_smile:

Adam Warner wrote:

Hi Reid Spencer,

> CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure
> make
>
> and was able to reproduce the problem. Not sure what's up with that but
> as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its
> just 3.4ish. I also concur with him that you should file a bug and
> attach the pre-processed source to it. You can get that with the -E flag
> to GCC.

Many thanks for everyone's wonderful replies.

I added the -E flag to the build options. Are the preprocessed sources the
.o files that now look something like this:

# 1 "/home/adam/t/t5/freetype-2.1.9/src/sfnt/sfnt.c"
# 1 "/home/adam/t/t5/freetype-2.1.9//"
# 1 "/home/adam/t/t5/freetype-2.1.9/src/sfnt/sfnt.c"
# 1 "<built-in>"
# 1 "<command line>"
...
typedef int _G_int16_t __attribute__ ((__mode__ (__HI__)));
typedef int _G_int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned int _G_uint16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int _G_uint32_t __attribute__ ((__mode__ (__SI__)));

Yup, that would be the preprocessed sources!

...

...because there's 4.8MB of them and I'd first like to confirm this is
what I should be attaching. I'm sorry but at this stage I don't have the
capabilities to narrow down the FreeType source code to a minimum test
case (unless the FreeType source code happens to looks uncannily like the
C version of Hello, World!)

Can you just capture the pre-processed source for the one FreeType file
that produces the errors about the non-constant initialization? Just see
what the makefile spits out for a compilation command for that one file
and change "-c" to "-E". Hopefully that's not multi-megabyte. If it is,
please compress it with gzip before attaching it to the bug.

Thanks,

Reid.

Adam sent me his tar file and only one file in it needs to be attached to a bug report, and it's only about 260KB. The initialization that causes the errors is below. I'm sure I can prune it down significantly.

    static const FT_Frame_Field header_fields =
    {

      { ft_frame_start, 0, 54 },
        { ft_frame_ulong_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Table_Version ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Table_Version) ) },
        { ft_frame_ulong_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Font_Revision ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Font_Revision) ) },
        { ft_frame_long_be, (FT_Byte)sizeof ( ((TT_Header*)0)->CheckSum_Adjust ), (FT_UShort)( ((size_t) &((TT_Header *)0)->CheckSum_Adjust) ) },
        { ft_frame_long_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Magic_Number ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Magic_Number) ) },
        { ft_frame_ushort_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Flags ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Flags) ) },
        { ft_frame_ushort_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Units_Per_EM ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Units_Per_EM) ) },
=================== Errors start with the next line ===============
        { ft_frame_long_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Created[0] ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Created[0]) ) },
        { ft_frame_long_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Created[1] ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Created[1]) ) },
        { ft_frame_long_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Modified[0] ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Modified[0]) ) },
        { ft_frame_long_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Modified[1] ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Modified[1]) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->xMin ), (FT_UShort)( ((size_t) &((TT_Header *)0)->xMin) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->yMin ), (FT_UShort)( ((size_t) &((TT_Header *)0)->yMin) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->xMax ), (FT_UShort)( ((size_t) &((TT_Header *)0)->xMax) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->yMax ), (FT_UShort)( ((size_t) &((TT_Header *)0)->yMax) ) },
        { ft_frame_ushort_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Mac_Style ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Mac_Style) ) },
        { ft_frame_ushort_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Lowest_Rec_PPEM ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Lowest_Rec_PPEM) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Font_Direction ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Font_Direction) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Index_To_Loc_Format ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Index_To_Loc_Format) ) },
        { ft_frame_short_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Glyph_Data_Format ), (FT_UShort)( ((size_t) &((TT_Header *)0)->Glyph_Data_Format) ) },
      { ft_frame_end, 0, 0 }
    };

Reid Spencer wrote:

Hi Jeff Cohen,

Adam sent me his tar file and only one file in it needs to be attached
to a bug report, and it's only about 260KB.

Yes, sfnt.o is the file I was intending to upload. Many thanks for the
confirmation and analysis. Here's the bug report:
<http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=487&gt;

I hit Enter outside the text box which submitted the bug report before it
was complete and tidy, though I believe it's decipherable. I added the
link back to this discussion as an attachment comment.

Thanks again to all,
Adam