Hello, As explained previously, the 'otvalid' module cannot be compiled as found in 2.1.10 because we're using legal C preprocessing tricks that are not supported by the Visual C++ compiler.
In case you're interested by this module, you can check out the current CVS version, since I've recently commited a fix to the source code (we're still using the preprocessor, but with different subtle tricks :-) which now compiles normally. Another possibility, as suggested is to simply not compile it and remove its reference from <freetype/config/ftmodule.h> Regarding the FT_EXPORT thing: the source code is by default agnostic to ABI conventions, which means you shouldn't need to change anything in it (unless you'd want to produce a DLL). I suppose that the __fastcall default comes from the project file you've been using to build the library. In this case, just switching the project's "calling convention" setting to __cdecl should be enough. Hope this helps, - David Turner - The FreeType Project (www.freetype.org) > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > la part de > Xerxes > Envoyé : mercredi 29 juin 2005 23:31 > À : freetype-devel@nongnu.org > Objet : [ft-devel] unresolved external symbol _otv_module_class > > > Hello, > > We were previously using FreeType 2.1.9 with our project and recently > attempted to upgrade to the most recent 2.1.10 release. We are > statically linking freetype and are using Microsoft Visual Studio .NET > 2003. > > Anyways, I am able to compile freetype, but when I go to link our > project, we get a linker error as follows: > > freetype2110_d.lib(ftinit.obj) : error LNK2001: unresolved external > symbol _otv_module_class > > Does anyone have any idea as to what might be causing this problem? > The previous version linked with our project just fine. > > Also, I do not think it is related, but just in case it is.. I had to > change the FT_EXPORT macro in ftconfig.h to explicitly include the > _cdecl calling convention. Since our project uses the __fastcall > calling convention, and since freetype doesn't explicitly specify, > when compiling our project, it assumes __fastcall for freetype as > well, but that is not right. > > Anyways, any help is much appreciated. > > Thanks. > > > _______________________________________________ > Freetype-devel mailing list > Freetype-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/freetype-devel > _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
