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 Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
>> 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?Debian's mingw32 libgcc.a doesn't have __eprintf in either of these versions: 3.4.5.20060117.1.dfsg-2 4.2.1.dfsg-1 These were the only versions I could find. The official mingw32 libgcc.a does have __eprintf, in both of these versions: gcc-3.4.5-20060117-3 gcc-4.3.0-20080502-mingw32-alpha Thanks, 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?GCC's gcc/configure has this logic: # If this is using newlib, without having the headers available now, # then define inhibit_libc in LIBGCC2_CFLAGS. # This prevents libgcc2 from containing any code which requires libc # support. inhibit_libc=false if { { test x$host != x$target && test "x$with_sysroot" = x ; } || test x$with_newlib = xyes ; } && { test "x$with_headers" = x || test "x$with_headers" = xno ; } ; then inhibit_libc=true fi Debian's mingw32 package is built with host != target, and without the --with-sysroot and --with-headers options. So this logic kicks in, and prevents __eprintf from being built in libgcc.a, since it calls into libc.>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. Thanks, Jay.
> 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't actually test it. Anyway, I'd vote for removing all references to __eprintf from lib/System/Win32/DynamicLibrary.inc. Thanks, Jay.
Possibly Parallel Threads
- [LLVMdev] AnalysisUsage & Call Graph SCC Pass Manager
- [LLVMdev] Problem in External/SPEC/CFP2000/177.mesa/Makefile ?
- [LLVMdev] LLVM-GCC & GV zeroinitializers, 2.5 vs 2.6.
- [LLVMdev] Pre pr4572 lvm-gcc building/working revision needed
- [LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor