[LLVMdev] Compiling FreeType 2.1.9 with LLVM 1.4

[Reid Spencer]

On Sun, 2004-12-19 at 20:20, 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>
> <http://groups.google.co.nz/groups?th=608e6e38e496f09d>
> (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 ;-)

Hey, YOU found out! :)

> 
> 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:
> <http://sourceforge.net/project/showfiles.php?group_id=3157>
> 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 :)

Reid

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041219/027f3bb7/attachment.sig>