[SOLVED]Static linking a dll - why isn't this working?

[OceanMachine]

Hi All,

I am trying to compile my code into a single DLL (or at least the CEGUI code) so that when I inject it into another process, there aren't loads of dependency DLLs that have to be in the process's directory.
However, I am having some problems getting the DLL to build with the config I have, and maybe I am not understanding something. I have read quite a few threads on the forum about static linking, but all of the ones I have seen seem to have had different solutions (that either don't relate to the problem's I'm having, or have solutions that I have already tried/impelemented in an attempt to get this working).

I already have #define CEGUI_STATIC in my code. I also added CEGUI_STATIC to the Preprocessor Definitions. I have also changed the Runtime Library to use /MT. My Configuration Type is obviously still on "Dynamic Library". I changed all my libraries defined in the Additional Dependencies list to the _Static variants (e.g. changed CEGUIBase.lib to CEGUIBase_Static.lib, but now I am getting a load of unresolved external symbols when trying to build. I also tried changing STATIC_BUILD_WITH_DYNAMIC_DEPS to both true and false in config.lua and rebuiliding and this didn't seem to matter.

So I tried to start again...
-- I have edited Config.lua to add the DirectX SDK directories to CEGUI_EXTRA_PATHS and set STATIC_BUILD_WITH_DYNAMIC_DEPS to false.
-- Then I re-ran the build_cs2008.bat.
-- Then opened the resulting CEGUI.sln in VC++2010 and converted from the 2008 version to 2010.
-- Then I selected the Release_Static build version and rebuild the entire solution.
-- I then removed everything from all of the "VC++ Directories" lists.
-- I then added just the "cegui\include", "cegui\include\RendererModules\Direct3D9" and "DirectXSDK\Include" directories into the "Additional Include Directories" list.
-- I added the Microsoft SDK Lib directory to the "Additional Library Directories" list
-- I made sure "CEGUI_STATIC" was in the Preprocessor Definitions.
-- I added all of the static versions of the files into the "Additional Dependencies" list by full path to make sure I was using the static versions. These are what I have:

C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIBase_Static.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIDirect3D9Renderer_Static.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIFalagardWRBase_Static.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIExpatParser_Static.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUISILLYImageCodec_Static.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\pcre.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\expat.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\SILLY.lib

I still had a load of unresolved external sybmol errors, so I changed SILLY.lib in the list above to use the one in the /dynamic directory and this seemed to get rid of those problems (not sure if it was the correct thing to do), but I am still having some others, seemingly to do with CEGUIBase. I am not sure what else I have to do to get this statically linking all the CEGUI code, but I still have the following unresolved external errors:

Code: Select all

1>     Creating library C:\Users\smokedog\Desktop\DirectX\Direct3D-Hook\Release\Direct3D-Hook.lib and object C:\Users\smokedog\Desktop\DirectX\Direct3D-Hook\Release\Direct3D-Hook.exp
1>Direct3D-Hook.obj : error LNK2019: unresolved external symbol __imp__PathStripPathA@4 referenced in function _DllMain@12
1>CEGUIBase_Static.lib(CEGUISystem.obj) : error LNK2019: unresolved external symbol __imp__timeGetTime@0 referenced in function "public: static double __cdecl CEGUI::SimpleTimer::currentTime(void)" (?currentTime@SimpleTimer@CEGUI@@SANXZ)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Load_Char referenced in function "protected: unsigned int __thiscall CEGUI::FreeTypeFont::getTextureSize(class std::_Tree_const_iterator<class std::_Tree_val<class std::_Tmap_traits<unsigned int,class CEGUI::FontGlyph,struct std::less<unsigned int>,class std::allocator<struct std::pair<unsigned int const ,class CEGUI::FontGlyph> >,0> > >,class std::_Tree_const_iterator<class std::_Tree_val<class std::_Tmap_traits<unsigned int,class CEGUI::FontGlyph,struct std::less<unsigned int>,class std::allocator<struct std::pair<unsigned int const ,class CEGUI::FontGlyph> >,0> > >)const " (?getTextureSize@FreeTypeFont@CEGUI@@IBEIV?$_Tree_const_iterator@V?$_Tree_val@V?$_Tmap_traits@IVFontGlyph@CEGUI@@U?$less@I@std@@V?$allocator@U?$pair@$$CBIVFontGlyph@CEGUI@@@std@@@4@$0A@@std@@@std@@@std@@0@Z)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Done_Face referenced in function "protected: void __thiscall CEGUI::FreeTypeFont::free(void)" (?free@FreeTypeFont@CEGUI@@IAEXXZ)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Get_Next_Char referenced in function "protected: virtual void __thiscall CEGUI::FreeTypeFont::updateFont(void)" (?updateFont@FreeTypeFont@CEGUI@@MAEXXZ)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Get_First_Char referenced in function "protected: virtual void __thiscall CEGUI::FreeTypeFont::updateFont(void)" (?updateFont@FreeTypeFont@CEGUI@@MAEXXZ)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Set_Char_Size referenced in function "protected: virtual void __thiscall CEGUI::FreeTypeFont::updateFont(void)" (?updateFont@FreeTypeFont@CEGUI@@MAEXXZ)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_New_Memory_Face referenced in function "protected: virtual void __thiscall CEGUI::FreeTypeFont::updateFont(void)" (?updateFont@FreeTypeFont@CEGUI@@MAEXXZ)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Init_FreeType referenced in function "public: __thiscall CEGUI::FreeTypeFont::FreeTypeFont(class CEGUI::String const &,float,bool,class CEGUI::String const &,class CEGUI::String const &,bool,float,float,float)" (??0FreeTypeFont@CEGUI@@QAE@ABVString@1@M_N001MMM@Z)
1>CEGUIBase_Static.lib(CEGUIFreeTypeFont.obj) : error LNK2019: unresolved external symbol _FT_Done_FreeType referenced in function "public: virtual __thiscall CEGUI::FreeTypeFont::~FreeTypeFont(void)" (??1FreeTypeFont@CEGUI@@UAE@XZ)
1>C:\Users\smokedog\Desktop\DirectX\Direct3D-Hook\Release\Direct3D-Hook.dll : fatal error LNK1120: 10 unresolved externals


Here is my compiler command line:

Code: Select all

/I"C:\Utilities\CEGUI-SDK-0.7.5-vc10\cegui\include\RendererModules\Direct3D9" /I"C:\Utilities\Microsoft DirectX SDK (June 2010)\Include" /I"C:\Utilities\CEGUI-SDK-0.7.5-vc10\cegui\include" /Zi /nologo /W3 /WX- /O2 /Oy- /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "DIRECT3DHOOK_EXPORTS" /D "_CRT_SECURE_NO_DEPRECATE" /D "CEGUI_STATIC" /D "_WINDLL" /D "_MBCS" /Gm- /EHsc /MT /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"Release\Direct3D-Hook.pch" /Fa"Release\" /Fo"Release\" /Fd"Release\vc100.pdb" /Gd /analyze- /errorReport:queue 

and here is my linker command line:

Code: Select all

/OUT:"C:\Projects\Direct3D-Hook\Release\Direct3D-Hook.dll" /NOLOGO /LIBPATH:"C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib" /LIBPATH:"C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\ReleaseWithSymbols" /LIBPATH:"C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static" /LIBPATH:"C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\dynamic" /LIBPATH:"C:\Utilities\Microsoft DirectX SDK (June 2010)\Lib\x86" /DLL "C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIBase_Static.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIDirect3D9Renderer_Static.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIFalagardWRBase_Static.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUIExpatParser_Static.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\lib\CEGUISILLYImageCodec_Static.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\pcre.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\expat.lib" "C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\dynamic\SILLY.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /MANIFEST /ManifestFile:"Release\Direct3D-Hook.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:"C:\Projects\Direct3D-Hook\Release\Direct3D-Hook.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /PGD:"C:\Projects\Direct3D-Hook\Release\Direct3D-Hook.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE

[Edit:] I just tried chainging STATIC_BUILD_WITH_DYNAMIC_DEPS back to true, rebuilding the CEGUI solution in Release mode, and changing my dependencies in my project to use the Dynamic subdirectories, and changing my Runtime to MT and MD, and although my project builds with either of these Runtimes, my game still complains about missing CEGUIBase.dll as soon as it is injected.

[Jamarr]

STATIC_BUILD_WITH_DYNAMIC_DEPS to false...I still had a load of unresolved external sybmol errors

Translation: you are building a static-library (.lib) for CEGUI; this library's dependencies are also static-libraries (.libs). The linker errors indicate that the linker cannot find symbols (functions/variables/etc.) in the existing libraries you have specified.

To answer this, you must determine what additional libraries your project is dependent on and add them to the linkers dependency list. There are various ways to do this, but we can guess from the majority of the errors you are missing the FreeType library (note all of the FreeType references), as well as winmm.lib (note the timeGetTime reference); you'll have to figure out what library PathStripPath belongs to yourself.

my game still complains about missing CEGUIBase.dll as soon as it is injected.

Translation: the executable cannot find CEGUIBase.dll.

To answer this, you must determine how executables normally find DLLs. You can find the answer to this yourself using the search tool for this forum or via google. But basically all dll-dependencies need to be in the working directory of the executable; the 'working directory' can vary depending on how you 'run' the executable.

[OceanMachine]

Thanks for the response. I am trying to build a DLL for use by another application. I want to be able to load my DLL and it contain all of the required CEGUI code so that I don't need to have 6 CEGUI DLLs in the same directory as any game that I want to use. I don't want to build a .lib, unless I can also build a DLL from it.

I said that I have set STATIC_BUILD_WITH_DYNAMIC_DEP to true originally. and linked all the libraries to it. I set everything I thought I needed to static configuration (apart from the Configuration Type which is still .dll) and I thought this would do it.

Translation: the executable cannot find CEGUIBase.dll.

I realise that! This is because I don't want it to depend on that DLL and the other 5, I would like to include all the code I need for my GUI in my DLL. Is that not possible? I was checking to see if I had managed to get rid of the dependencies on the CEGUI dlls by rebuilding after changing some options.

Is there any way for me to know which libraries I need without guessing? I know that I might be able to work it out by luck and deduction by looking at the names of some of the functions, but is there any way to know for sure which libraries contain which symbols?

TIA

[Jamarr]

I want to be able to load my DLL and it contain all of the required CEGUI code so that I don't need to have 6 CEGUI DLLs

Then you do not want a static build. You want a dynamic build with statically-linked dependencies. This is unfortunately a bit more difficult, and I do not think there is a DYNAMIC_WITH_STATIC_DEPS configuration flag. The biggest problem is that CEGUI is composed of several /separate/ modules: base, falagard, xml-parser, image-codec, and render-module. You would have to create a new project that imports each of these and then re-exports every symbol as if they belong to the resulting module.

There may be other ways to do this, but this may be one option*:
1) create a new project
2) link to each library statically (make sure their dependencies are also statically-linked to them)
3a) Add the preprocessor symbols to export each module (CEGUIBASE_EXPORTS, etc); you can look these up in each projects Release configuration
3b) If option a does not work, you may have to use a .DEF file

*Note that although this does intrigue me, I have never had a need to try this so it is hypothetical.

Is there any way for me to know which libraries I need without guessing?

You know google provides a vast knowledge of answers, if you know how to ask the question
Dumpbin.exe

[OceanMachine]

Ok, thanks for your advice - I will see what I can do... Although this confuses me as it seems to go against what Kulik told me in this thread about being able to statically link... hence why I started this separate thread!

Maybe Kulik knows if there is such a flag to create a Dynamic build with statically linked deps?

[Kulik]

You don't need a dynamic CEGUI build. You need a static CEGUI build with static deps and your DLL will link to it and your DLL will be dynamic.

To be honest I don't have much experience with static builds so don't rely on the info but I think it should work

EDIT: As for the linking errors, add winmm.lib and freetype_static.lib (or whatever it's called).

[Jamarr]

There is definitely some confusion here both in terminology and in what you are trying to do....as always seems to be the case with this issue.

First, the terminology is being used in different ways. We basically described a similar approach. When Kulik uses the terms dynamic and static he is implying (or limiting it to the scope of) linking; where as I explicitly add -build or -linking to clarify my intention. If I say "dynamic build" I mean building-a-dynamically-linked-library, and if I say dynamic linking I mean dynamically-linking-to-a-library; same goes for the term static. These are two sides of the same coin.

Second, I think Kulik is assuming you want to statically-link CEGUI into a single DLL that will use CEGUI internally via your own GUI management code. In this scenario you only need to link to CEGUI statically. The linker will embed CEGUI implicitly; that is, only the portions of CEGUI your GUI management code uses will be included. In this case, the symbols in the CEGUI library will not be exposed through this DLL; rather, you would expose your management code which uses CEGUI internally.

However, my interpretation of your post is that you actually want to merge the existing CEGUI DLLs into a single CEGUI DLL that exports all CEGUI symbols from this single module. In this case, the DLL will not contain any GUI management code; it will consist solely and entirely of CEGUI. If this is the case, as I previously described and similar to the above, you need to statically-link CEGUI into a new DLL project. However, you have to take this a step further. Since the linker does not implicitly know what to include/exclude from the build, you need to explicitly tell the linker which (CEGUI) symbols you want to expose.

So to summarize: if you only need your DLL to use CEGUI internally then a "static CEGUI build" is sufficient; however, if you want a single monolithic DLL that exposes all of CEGUI you must take additional steps to transform a "static CEGUI build" into a "dynamic CEGUI build".

[OceanMachine]

So to summarize: if you only need your DLL to use CEGUI internally

Yes, This.

I'm sorry, when I said

I want to be able to load my DLL and it contain all of the required CEGUI code so that I don't need to have 6 CEGUI DLLs

I wasn't specific enough - I meant only the CEGUI code that my GUI needs to be able to run, not all the code in the whole solution

Sorry, I should have been clearer. Basically, I have my own GUI-specific setup code written that is obviously using the CEGUI libraries (and other) libraries required to get the GUI building. I want to be able to output a single DLL that I can then inject into another process, and this DLL should contain all of my own specific GUI code, along with any CEGUI dependencies that are required just to get my own GUI working, all in one DLL. At the moment I am building my DLL fine and injecting it, but it has external dll dependencies and always requires the 6 specific CEGUI dlls that relate to my GUI to be in the working directory of the process into which I am injecting my own project dll. I wondered if it is possible to create one DLL that I can inject that will contain both my own GUI code and any other CEGUI code/symbols that are need for it to run, to avoid having to provide the CEGUIBase.dll, etc separately?

I apologise if my terminology was confusing - as you can probablly guess, I am fairly new to this, but trying to learn. I feel that I am most of the way there, but for some reason my build just wasn't working.

Given this info, does it look like the configuration I have said above (in the first post) correct, apart from the extra libraries, do you think? i.e. Rebuild cegui with STATIC_BUILD_WITH_DYNAMIC_DEPS = false and link to all the _Static libraries, using MT runtime config? If this is the case, then why do I get unresolved symbols when specifying the static version of SILLY.lib in the linker dependencies list, but not get the errors when specifying the dynamic version?

I will try this when I get home.. if it is as easy as just adding those 2 extra libraries then I will kick myself.

[Jamarr]

Given this info, does it look like the configuration I have said above (in the first post) correct, apart from the extra libraries, do you think? i.e. Rebuild cegui with STATIC_BUILD_WITH_DYNAMIC_DEPS = false and link to all the _Static libraries, using MT runtime config?

Yes. This is a similar configuration to what I use for CEGUI; the main difference in my case being that I built all of the libraries/dependencies myself instead of using the precompiled packages.

If this is the case, then why do I get unresolved symbols when specifying the static version of SILLY.lib in the linker dependencies list, but not get the errors when specifying the dynamic version?

I do not know why this affect would result from that change. The only thing "unresolved symbols" means is that the linker cannot find the symbol in any of the supplied modules, and as SILLY has nothing to do with FreeType or winmm I do not see how this single change could result in the linker magically finding non-existent FreeType or winmm symbols in the DLL version of SILLY.lib. There must have been other, additional changes to resolve those symbols. At least to the best of my knowledge.

I will try this when I get home.. if it is as easy as just adding those 2 extra libraries then I will kick myself.

I think you will find this to be the case

[OceanMachine]

the main difference in my case being that I built all of the libraries/dependencies myself instead of using the precompiled packages.

So am I, that's why I was talking about config.lua and running premake rebuilding the whole CEGUI solution

I do not know why this affect would result from that change

Not all of the unresolved externals, I meant just the SILLY ones went away when I specified the dynamic .libs. Although of course this is the wrong lib to use in my case.

OK, so I have managed to remove all the "unresolved external symbol" problems, apart from the ones related to SILLY.lib.

I am building with /MT Runtime Library configuration, and I thought that the version of SILLY.lib in the precompiled dependencies/static directory should match this? When I change to the one in the dependencies/dynamic subdirectory, the "unresolved external symbol" errors go away, but this leaves me with a dependency on the SILLY.dll, which I would like to avoid.

How do I get round this? Do I need to rebuild SILLY by donwloading it from the downloads page or something like that?

Here are the errors I have, and thanks in advance for any further (hopefully final) pointers:

Code: Select all

1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_error referenced in function "void __cdecl SILLY::PNG_read_function(struct png_struct_def *,unsigned char *,unsigned int)" (?PNG_read_function@SILLY@@YAXPAUpng_struct_def@@PAEI@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_io_ptr referenced in function "void __cdecl SILLY::PNG_read_function(struct png_struct_def *,unsigned char *,unsigned int)" (?PNG_read_function@SILLY@@YAXPAUpng_struct_def@@PAEI@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_channels referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_bit_depth referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_read_png referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_set_read_fn referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_set_error_fn referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_set_longjmp_fn referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_create_info_struct referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_create_read_struct referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::PNGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@PNGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYPNGImageLoader.obj) : error LNK2019: unresolved external symbol _png_get_rows referenced in function "public: virtual bool __thiscall SILLY::PNGImageLoader::loadImageData(enum SILLY::PixelOrigin,class SILLY::DataSource *,class SILLY::ImageContext *)" (?loadImageData@PNGImageLoader@SILLY@@UAE_NW4PixelOrigin@2@PAVDataSource@2@PAVImageContext@2@@Z)
1>SILLY.lib(SILLYJPGImageLoader.obj) : error LNK2019: unresolved external symbol _jpeg_finish_decompress referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::JPGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@JPGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYJPGImageLoader.obj) : error LNK2019: unresolved external symbol _jpeg_start_decompress referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::JPGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@JPGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYJPGImageLoader.obj) : error LNK2019: unresolved external symbol _jpeg_read_header referenced in function "public: virtual class SILLY::ImageContext * __thiscall SILLY::JPGImageLoader::loadHeader(enum SILLY::PixelFormat &,class SILLY::DataSource *)" (?loadHeader@JPGImageLoader@SILLY@@UAEPAVImageContext@2@AAW4PixelFormat@2@PAVDataSource@2@@Z)
1>SILLY.lib(SILLYJPGImageLoader.obj) : error LNK2019: unresolved external symbol _jpeg_read_scanlines referenced in function "public: virtual bool __thiscall SILLY::JPGImageLoader::loadImageData(enum SILLY::PixelOrigin,class SILLY::DataSource *,class SILLY::ImageContext *)" (?loadImageData@JPGImageLoader@SILLY@@UAE_NW4PixelOrigin@2@PAVDataSource@2@PAVImageContext@2@@Z)
1>SILLY.lib(SILLYPNGImageContext.obj) : error LNK2019: unresolved external symbol _png_destroy_read_struct referenced in function "public: virtual __thiscall SILLY::PNGImageContext::~PNGImageContext(void)" (??1PNGImageContext@SILLY@@UAE@XZ)
1>SILLY.lib(SILLYPNGImageContext.obj) : error LNK2019: unresolved external symbol _png_get_image_height referenced in function "private: void __thiscall SILLY::PNGImageContext::setImageSize(void)" (?setImageSize@PNGImageContext@SILLY@@AAEXXZ)
1>SILLY.lib(SILLYPNGImageContext.obj) : error LNK2019: unresolved external symbol _png_get_image_width referenced in function "private: void __thiscall SILLY::PNGImageContext::setImageSize(void)" (?setImageSize@PNGImageContext@SILLY@@AAEXXZ)
1>SILLY.lib(SILLYJPGImageContext.obj) : error LNK2019: unresolved external symbol _jpeg_std_error referenced in function "public: __thiscall SILLY::JPGImageContext::JPGImageContext(void)" (??0JPGImageContext@SILLY@@QAE@XZ)
1>SILLY.lib(SILLYJPGImageContext.obj) : error LNK2019: unresolved external symbol _jpeg_CreateDecompress referenced in function "public: __thiscall SILLY::JPGImageContext::JPGImageContext(void)" (??0JPGImageContext@SILLY@@QAE@XZ)
1>SILLY.lib(SILLYJPGImageContext.obj) : error LNK2019: unresolved external symbol _jpeg_resync_to_restart referenced in function "public: __thiscall SILLY::JPGImageContext::JPGImageContext(void)" (??0JPGImageContext@SILLY@@QAE@XZ)
1>SILLY.lib(SILLYJPGImageContext.obj) : error LNK2019: unresolved external symbol _jpeg_destroy_decompress referenced in function "public: virtual __thiscall SILLY::JPGImageContext::~JPGImageContext(void)" (??1JPGImageContext@SILLY@@UAE@XZ)
1>C:\Users\smokedog\Desktop\DirectX\Direct3D-Hook\Release\Direct3D-Hook.dll : fatal error LNK1120: 22 unresolved externals

[Edit: managed to work out that I also needed some other libraries that SILLY depends on. Ended up using the static version of SILLY.lib, and then added these on to the dependencies too:

C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\libpng.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\jpeg.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\libmng.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\libtiff.lib
C:\Utilities\CEGUI-SDK-0.7.5-vc10\dependencies\lib\static\zlib.lib

Of course as well as /dependencies/freetype.lib and (directx sdk) Winmm.lib as suggested before (in case it helps anyone else who has the same problem as me in the future).

Thanks to both of you for your help!! I shall mark this as solved. I appreciate the time and patience you took with me I'm sure it won't be the last time you'll be hearing from me