llvm dev - Apr 2009 - [LLVMdev] mingw build problems

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.