[Mingw-users] [64-bit mingw] Leading underscore or not?

[Patrick H. <pa...@13...>]

I am still plugging away with 64-bit MinGW stuff, and I have run into a
particularly tricky issue. It seems that the 64-bit Visual C++ 8.0 compil=
er
does not put a leading underscore on C symbols. The cross-compiler build =
of
GCC 4.3.0 that I am using does, and that means that a 64-bit C library bu=
ilt
using MinGW fails to resolve symbols needed by code compiled by Visual C+=
+
that is linking against that C library.

What behavior should be expected here? I can use -fno-leading-underscore
when I build the C library using GCC 4.3, but then I think I am running t=
he
risk of not being able to have symbols from MinGW libraries be resolved. =
(So
far, this is the case for snprintf() and round() in the case of the libra=
ry
I am working with). If I could generate static libraries (see the "Binuti=
ls
version for 64-bit MinGW" thread), then I could rebuild the MinGW CRT wit=
h
-fno-leading-underscore. Of course, then I expect that I would have to bu=
ild
all 64-bit code on MinGW with -fno-leading-underscore. If I want librarie=
s
MinGW-compiled to be able to be linked with 64-bit code compiled by Visua=
l
C++ 8, I think I have to do it that way.

Are there other ways of dealing with this? Ideally, I would use a #pragma=
 or
something in my code being compiled by Visual C++ before and after includ=
ing
the headers from the C library compiled with GCC. I don't know if such a
thing can actually be done, and it might just end up interfering with C
symbols from the MSVC 8 runtime. Maybe I just need to recompile GCC 4.3
again with some flag that tells is not to put the leading underscore on
function symbols that it generates.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/