Sargrad, Dave wrote: > I created a visual studio solution using cmake. What CMake command line did you use?
> I've also downloaded zlib, and freetype2, (libjpeg also). > > I build freetype2 without a problem using visual studio. > > When I build podofo all the projects seem to build except podofo_shared > does not link. The CMake files provided with PoDoFo at present aren't really flexible enough to be nice on windows - they make too many assumptions about library naming, since they're much better tested in the UNIX world. I've done a bunch of work in Scribus recently to improve its library search on Windows, and will adapt it to PoDoFo soon. It still won't, and can't, be automatic, but you'll at least be able to specify (eg) -DFREETYPE_LIB_NAME=freetype235MT_D . That's not done yet, though. Since the present build instructions recommend the use of a pre-built freetype that'll be fine anyway, it wasn't generally much of an issue. > Neither of these attempts allowed the linker to find symbols such as > FT_Init_FreeType. > > This seems like some kind of name mangling problem. However I am > building both podofo and freetype2 with the same compiler/linker. [I realise you've worked around this now by using prebuilt libraries, but it's still worth looking into.] On Windows, one of the issues that can come up is that of calling conventions. I've seen cases where a library's build system will set some defines so that its headers prototype all public functions as stdcall during the library build. If you don't set the same defines when compliling code that'll be linked to the library it might default to assuming these functions use the cdecl calling convention. This will result in a link failure. Unfortunately, the win32 ABI distinguishes symbols using stdcall from those using cdecl by adding a leading underscore. This is not exactly clear and unambiguous. Calling convention confusion could be what's going on with your zlib link errors, eg _inflate . If this is the case, you'll probably see a symbol just named "inflate" when you look at the zlib DLL or import library's symbol table. The same issue could well be arising with freetype, but this time affecting the DLL import stubs (__imp__blah). I wouldn't be too surprised if you found ___imp__FT_Done_Face (three leading underscores) instead of __imp__FT_Done_Face (two leading underscores) in freetype's exported symbol table. In the case of zlib, you should just use the pre-built DLL provided by the zlib project. For freetype, it's probably preferable not to use a DLL built with gcc in a Visual Studio project. Since freetype is pretty careful with memory management (if it passes allocated memory, it requires you to call a function in freetype to free it, etc) and we don't ever pass it a FILE* it shouldn't really matter much. Nonetheless, if you can get a freetype build to behave with visual studio that'd be preferable. I built Freetype using visual studio for Scribus recently and I had no particular issues. I may have built a static library, though. For Windows software I prefer to use static libraries unless the library has a widely-published and highly compatible binary (eg zlib) or there's a specific reason to use a DLL. The only specific reason I usually encounter is needing to use the same library in several executables I'm distributing, where a DLL becomes attractive for size reasons. -- Craig Ringer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
