search for: tmpu_bcho

Hi Gregory, > I'm looking at compiling some pieces of the standard library with llvm but I'm > running into problems with some functions being renamed by dragonegg. For > example, when I compile the acos implementation with plain gcc I get: > > $ nm acos.o > 0000000000000000 r .LC1 > 0000000000000048 r .LC10 > 0000000000000050 r .LC11 > 0000000000000058 r .LC12

Hello, I'm looking at compiling some pieces of the standard library with llvm but I'm running into problems with some functions being renamed by dragonegg. For example, when I compile the acos implementation with plain gcc I get: $ nm acos.o 0000000000000000 r .LC1 0000000000000048 r .LC10 0000000000000050 r .LC11 0000000000000058 r .LC12 0000000000000060 r .LC13 0000000000000068 r .LC14

...hen I try to compile uClibc with llvm. I've attached the .o and the .bc for comparison. The text file is the result after preprocessing (to avoid having to download a bunch of stuff). Here is the compile line that I'm running for the llvm compilation: llvm-gcc -emit-llvm -S -c pp.c -o /tmp/tmpU_bCHo.ll -c llvm-as /tmp/tmpU_bCHo.ll -o=pp.bc.o (note that llvm-gcc is gcc-4.5 setup to generate assembly when it gets -emit-llvm). The non-llvm compilation is from: gcc-4.5 -c pp.c -o pp.o I thought this was something coded into llvm, but maybe it is just my scripts messing things up somehow... On T...