[LLVMdev] Compiling FreeType 2.1.9 with LLVM 1.4
Reid Spencer
reid at x10sys.com
Sun Dec 19 21:15:52 PST 2004
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.
On Sun, 2004-12-19 at 21:05, Reid Spencer wrote:
> 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
>
>
> ______________________________________________________________________
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- 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/4e9ed3b1/attachment.sig>
More information about the llvm-dev
mailing list