Unresolved external symbol

[Sisyphus]

----- Original Message ----- 
From: "Chris Saunders" <evas at mountaincable.net>
To: <gmp-discuss at gmplib.org>
Sent: Saturday, June 05, 2010 4:45 AM
Subject: Unresolved external symbol


> I may have received no replies because the question is considered 
> inappropriate for this list.  If that is the case I would appreciate 
> someone letting me know.

I think the question would be better asked elsewhere, though I'm not exactly 
sure where that place might be.
It's more a question of how to access a library using cl, when that library 
has been built with mingw - rather than anything to do with the gmp library 
specifically.

I think I have seen questions about accessing mingw-built libraries with cl 
on the mingw-users mailing list - so maybe try asking there (though I doubt 
that such matters are "on topic" for that list, either). Better to first 
search the mingw-users list archives, as the answers you need might already 
be there.

> Error LNK2019: unresolved external symbol
> ___mingw_vfprintf referenced in function _fprintf

I get the same error if I try to build the following program using 'cl' 
(building against mingw-built gmp):

#include <stdio.h>
#include <gmp.h>

int main(void) {
    mpf_t x;
    mpf_init_set_d(x, 10.5);
    mpf_out_str(stdout, 10, 0, x);
    mpf_clear(x);
    return 0;
}


Linking to the mingw library 'libmingwex.a' is the only way I can find of 
resolving that symbol - so give that a try. I presume you're already linking 
to the mingw library 'libgcc.a'.

I eventually got that script to build with 'cl' by linking to mingw's 
libmingwex.a, libgcc.a and libmsvcrt.a - but the build produced some 
warnings that I don't understand and the program crashes on execution ... 
that's as far as I went :-)
I'm using MSVC++7.0, which would not be ideal for such an activity - I think 
one would have a better chance of success if using MSVC++6.0. (This is 
because MSVC++6.0 and MinGW both use the same C runtime - namely, 
msvcrt.dll. MSVC++7.0 uses a different runtime - namely, msvcr70.dll.)

Anyway, see how you go with that - and feel free to follow this up with me 
*offlist*.

Cheers,
Rob