search for: __eprintf

Hello, Jay > but I don't understand what they are for. Do they let lli execute > programs in which the compiler has hard-coded calls to __eprintf? Does > that mean that __eprintf ought to be found in libgcc? Yes. And I believe it was there, at least for "official mingw gcc", which is 3.4.5. Could you please investigate why you don't have this in your libgcc? Is it gcc v3 vs v4 issue? --- With best regards, Anton Korobey...

The next problem I have is: llvm[2]: Linking Debug executable opt /home/foad/llvm/objdir-mingw/Debug/lib/libLLVMSystem.a(DynamicLibrary.o):/home/foad/svn/llvm-project/llvm/trunk/lib/System/Win32/DynamicLibrary.inc:179: undefined reference to `___eprintf' collect2: ld returned 1 exit status I can work around this by removing the two references to __eprintf from lib/System/Win32/DynamicLibrary.inc, but... why are they there in the first place, and why don't I have __eprintf on my system? I see that these references were introduced here: h...

>> but I don't understand what they are for. Do they let lli execute >> programs in which the compiler has hard-coded calls to __eprintf? Does >> that mean that __eprintf ought to be found in libgcc? > Yes. And I believe it was there, at least for "official mingw gcc", > which is 3.4.5. Could you please investigate why you don't have this > in your libgcc? Is it gcc v3 vs v4 issue? GCC's gcc/configu...

> From this discussion: > > http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00780.html > > it sounds like only code built with GCC 2.x will refer to __eprintf. Also, the official MinGW gcc-2.95.3 package doesn't include an assert.h, so it seems like MinGW has probably always used its own assert.h, not the version GCC used to provide, so no code built with MinGW would ever have referred to __eprintf. But I'm not 100% sure about this and I can'...

> I can work around this by removing the two references to __eprintf > from lib/System/Win32/DynamicLibrary.inc, but... why are they there in > the first place, and why don't I have __eprintf on my system? > > I see that these references were introduced here: > > http://llvm.org/viewvc/llvm-project?view=rev&revision=52037 > > but I do...

I'm trying to cross-compile LLVM with build=, host=target=. I'm using the following packages from Debian lenny: mingw32 4.2.1.dfsg-1 mingw32-binutils 2.18.50-20080109-1 mingw32-runtime 3.13-1 The first problem I hit was when I configured with CC, CXX, AR and RANLIB set to mingw cross-tools, but forgot to specify NM as well. This resulted in a load of warnings that scrolled off the

Hello, Jay > Also, the official MinGW gcc-2.95.3 package doesn't include an > assert.h, so it seems like MinGW has probably always used its own > assert.h, not the version GCC used to provide, so no code built with > MinGW would ever have referred to __eprintf. But I'm not 100% sure > about this and I can't actually test it. Thanks for tracking, this! > Anyway, I'd vote for removing all references to __eprintf from > lib/System/Win32/DynamicLibrary.inc. Agree. Julien, what do you think? -- With best regards, Anton Korobeynikov. F...

On Sat, Apr 18, 2009 at 12:13:55AM +0400, Anton Korobeynikov wrote: > > Anyway, I'd vote for removing all references to __eprintf from > > lib/System/Win32/DynamicLibrary.inc. > Agree. Julien, what do you think? That's fine with me. I'll test it once the change is made. Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F 4E5F FA3C 62DB 4AA7 B196 4A62 PGP Public Ke...

Hello, Aaron. > /usr/src/llvm-gcc4/gcc/libgcc2.c: In function '__eprintf': > /usr/src/llvm-gcc4/gcc/libgcc2.c:1832: internal compiler error: > Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://llvm.org/bugs> for instructions. You should: 1. Try to emit bytecode with --emit-llvm co...

I am getting an "--emit-llvm is not supported in this configuration" error on a release build on Cygwin, the debug build is fine. make[3]: Entering directory `/usr/build/llvm/runtime/GCCLibraries/libc' llvm[3]: Compiling atox.c for Release build (bytecode) llvm-gcc: --emit-llvm is not supported in this configuration. make[3]: ***

...CVS. There is one known problem (below), > > but otherwise it works as well as the static PowerPC backend on the test > > suite. > > > > The known problem is that the JIT seems unable to resolve calls to > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > This appears to be something funny in the darwin implementation of dlsym > > (returning null for symbols that are valid if they start with __). If > > anyone has any ideas of how to make this work, we would love to hear them. > > :) > > > >...

>> > Anyway, I'd vote for removing all references to __eprintf from >> > lib/System/Win32/DynamicLibrary.inc. >> Agree. Julien, what do you think? > > That's fine with me. I'll test it once the change is made. Here's the patch. I can't commit it myself. Thanks, Jay. -------------- next part -------------- A non-text attac...

...with clang - > against the LLVM libraries - compiled with gcc. (I thought about > compiling LLVM with clang, but then I'd have to compile it twice to > bootstrap.) > > Under OS X, I get the following error when I try to link: > > Undefined symbols: > > "___eprintf", referenced from: > > ___eprintf$non_lazy_ptr in > libLLVMSupport.a(SearchForAddressOfSpecialSymbol.cpp.o) > > ld: symbol(s) not found > > clang-3: error: linker command failed with exit code 1 (use -v to > see invocation) > Interesting....

...ndola wrote: > The problem comes from SearchForAddressOfSpecialSymbol.cpp: > > // FIXME: Currently disabled when using Clang, as we don't always > have our > // runtime support libraries available. > #ifndef __clang__ > #ifdef __i386__ > EXPLICIT_SYMBOL(__eprintf); > #endif > #endif > > Now, exactly what runtime library is not available is something that > someone more familiar with OS X will have to answer :-) The runtime support library the comment talks about is none other than compiler-rt. (Specifically, libclang_rt.eprintf.a.) If you c...

...king copy) @@ -134,6 +134,21 @@ #if defined(__MINGW32__) EXPLICIT_SYMBOL_DEF(_alloca); EXPLICIT_SYMBOL_DEF(__main); + EXPLICIT_SYMBOL_DEF(__ashldi3); + EXPLICIT_SYMBOL_DEF(__ashrdi3); + EXPLICIT_SYMBOL_DEF(__cmpdi2); + EXPLICIT_SYMBOL_DEF(__divdi3); + EXPLICIT_SYMBOL_DEF(__eprintf); + EXPLICIT_SYMBOL_DEF(__fixdfdi); + EXPLICIT_SYMBOL_DEF(__fixsfdi); + EXPLICIT_SYMBOL_DEF(__fixunsdfdi); + EXPLICIT_SYMBOL_DEF(__fixunssfdi); + EXPLICIT_SYMBOL_DEF(__floatdidf); + EXPLICIT_SYMBOL_DEF(__floatdisf); + EXPLICIT_SYMBOL_DEF(__lshrdi3); + EXPLICIT_SYMBOL_DEF(__m...

...ow operational and begging for testing in mainline CVS. There is one known problem (below), but otherwise it works as well as the static PowerPC backend on the test suite. The known problem is that the JIT seems unable to resolve calls to external functions that start with "__", such as __eprintf, __moddi3, etc. This appears to be something funny in the darwin implementation of dlsym (returning null for symbols that are valid if they start with __). If anyone has any ideas of how to make this work, we would love to hear them. :) -Chris -- http://llvm.org/ http://nondot.org/sabre/

...g for testing in mainline CVS. There is one known problem (below), > but otherwise it works as well as the static PowerPC backend on the test > suite. > > The known problem is that the JIT seems unable to resolve calls to > external functions that start with "__", such as __eprintf, __moddi3, etc. > This appears to be something funny in the darwin implementation of dlsym > (returning null for symbols that are valid if they start with __). If > anyone has any ideas of how to make this work, we would love to hear them. > :) > > -Chris -------------- next par...

...'m attempting to link my frontend - compiled with clang - against the LLVM libraries - compiled with gcc. (I thought about compiling LLVM with clang, but then I'd have to compile it twice to bootstrap.) Under OS X, I get the following error when I try to link: Undefined symbols: "___eprintf", referenced from: ___eprintf$non_lazy_ptr in libLLVMSupport.a(SearchForAddressOfSpecialSymbol.cpp.o) ld: symbol(s) not found clang-3: error: linker command failed with exit code 1 (use -v to see invocation) As you can see the reference is coming from the LLVM libs. Under Ubuntu, t...

...n problem (below), > > > but otherwise it works as well as the static PowerPC backend on the test > > > suite. > > > > > > The known problem is that the JIT seems unable to resolve calls to > > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > > This appears to be something funny in the darwin implementation of dlsym > > > (returning null for symbols that are valid if they start with __). If > > > anyone has any ideas of how to make this work, we would love to hear them. > > > :) &...

...gt; > > but otherwise it works as well as the static PowerPC backend on the test > > > > suite. > > > > > > > > The known problem is that the JIT seems unable to resolve calls to > > > > external functions that start with "__", such as __eprintf, __moddi3, etc. > > > > This appears to be something funny in the darwin implementation of dlsym > > > > (returning null for symbols that are valid if they start with __). If > > > > anyone has any ideas of how to make this work, we would love to hear them. >...