Using DLLs in C - c

This seems like a noob question, but all my searches return stuff about C++ or C# so I'm going to ask it here.
I have a DLL, SDL.dll, in the directory with my .c file. I want to import it to use.
using is not supported, #import doesn't work.

No directive in the source will help you, you can either
link to the DLL, use a so-called lib file for this. (This is a statically dynamic linking)
use LoadLibrary/FreeLibrary and GetProcAddress to map the addresses of functions to function pointers (true dynamic linking)
In the first case you also need an appropriate header file which matches the platform and version of the DLL used.
The second solution will work if you drop-in a newer version of the DLL as long as the prototypes of the functions used match.
This assumes you are under Windows, which is probably the case if you have a *.dll and not an *.so (shared object) file. (For Linux systems, you can include dlfcn.h and use dlopen/dlclose/dlsym instead of LoadLibrary/FreeLibrary/GetProcAddress with a slightly different syntax, check the doc)

this is quite possible assuming your DLL is in the correct form (the same standards as Windows API DLLs for example)
you need to declare you functions - perhaps in a header file, like this:
typedef void (CALLBACK *functionnameptr)(char *, int),
Then you use LoadLibrary to load the DLL, and provide a Handle to it:
handle = LoadLibrary("SDL.DLL");
Then you use GetProcAddress(handle,"real function name in DLL")
like this:
functionnameptr lptrfunction;
lptrfunction = GetProcAddress(handle,"real function name in DLL");
Now you can use the lptrfunction as you would normally use a function in C

Assuming you're using Visual Studio.
1.) Download http://www.libsdl.org/release/SDL-1.2.15.zip
2.) unzip and install to for example C:\SDL-1.2.15
3.) In Visual Studio open the properties of the project goto C++ general and add C:\SDL-1.2.15\include to "Additional include directories".
4.) Goto the "Linker" tab and add C:\SDL-1.2.15\lib\x86 to "Additional library directories".
5.) Now go to "Input" under the Linker tab and add SDL.lib; SDLmain.lib to "Additional dependencies"
6.) Go to the "Build Events" tab and "Post build event" and add copy /y C:\SDL-1.2.15\lib\x86\SDL.dll "$(OutDir)
That should do get your SDL working for Visual Studio in 32bit
On Linux if SDL is already installed just type "g++ -02 -o foo foo.cpp -lSDL"

Related

Eclipse CDT MinGW toolchain: how to link with a library that does not begin with lib prefix?

I have problems with linking to a library called xyz.a in my Eclipse CDT MinGW project. Eclipse projects cannot find this library unless I rename it to libxyz.a.
I have added:
library path to project via Properties/C C++ General/Paths and Symbols/Library Paths.
library name to project via Properties/C C++ General/Paths and Symbols/Libraries. Library name I specified here is xyz, so it's without extesion. What should I specify here in order to successfully include xyz.a without having to rename it to libxyz.a?
Some info I found online:
How do I specify the libraries to be searched by the linker?
MinGW supports libraries named according to the "<name>.lib" and "<name>.dll" conventions, in addition to the normal "lib<name>.a" convention common on *nix systems. To include libraries named according to any of these conventions, simply add an associated "-l<name>" specification to the compiler command, ensuring it is placed after the name of the module in which the reference appears.
Note that, if the library is not found in any of the default library search paths, you may also need to insert an appropriate "-L<dir>" switch to specify its location; (it is recommended that you place the "-L<dir>" switch before the "-l<name>" specification which requires it).
Also note that the library names "lib<name>.a" and "lib<name>.lib" are not equivalent; if you have a library named according to the aberrant "lib<name>.lib" convention, it will not be found by an "-l<name>" specification -- if you cannot rename the library, you must use the form "-llib<name>" instead.
You can link a library called oddname - where oddname includes any file-extension - in Eclipse CDT like this:
Navigate in the project Properties -> C/C++ Build -> Settings
-> Tool Settings -> GCC C++ Linker -> Libraries.
In Libraries(-l) panel add :oddname
If necessary, in the Library search path(-L) panel add the path to
oddname
OK out
This setting will add the option -l:oddname to the generated GCC link
command. -l:filename is the form of the -l option signifying that
the conventional lib prefix and the {.so|.a} extension are not implied and that
filename is the actual filename of the library to be linked. Here is the documentation
The simplest option is to just add the library to the command line of GCC. To do this with CDT add the library (whatever name it is) to the Other object (under Project settings -> C/C++ Build -> GCC C Linker -> Miscellaneous)
Here is a screenshot where I added a library with the file name badname.a to the command line of GCC.
When the build runs, this is the resultant command line:
Invoking: GCC C Linker
gcc -o "SO" ./src/SO.o /home/me/workspace/SO/badname.a
Note: the disadvantage of the above solution is the whole library is included, not just the objects within it that are referenced. You can alternatively add any linker flags you want by adding them to the Linker flags box in the same dialog.

How to avoid library finding CMakeLists feature

I'm trying to adjust 3rd person code to my needs. This code is provided with CMake config files used to build and install it. There is possibility to choose one of libraries. And in code is often used #ifdef USE_FTD2XX directive. I saw that this is defined in CMamkeFiles.txt file like here:
option(USE_FTD2XX "Use FTDI libFTD2XX instead of free libftdi" ON)
if(USE_FTD2XX)
find_package(libFTD2XX)
endif(USE_FTD2XX)
if(LIBFTD2XX_FOUND)
include_directories(${LIBFTD2XX_INCLUDE_DIR})
add_definitions( -DUSE_FTD2XX )
else(LIBFTD2XX_FOUND)
set(LIBFTD2XX_LIBRARIES "")
endif(LIBFTD2XX_FOUND)
But if I simply use *.c and *.cpp files and I analyse and run it simply from IDE (Codeblocks), how could I set using this library in C++ code instead of in CMake? I'm also sure that I want use always this one so it can be fixed.
Should I simply #define USE_FTD2XX in main file?
You cannot simply #define USE_FTD2XX because you also need specific linker options for this to work (i.e. the library to link with). If the option is OFF in cmake, the specific link options won't be present in the Makefile and most likely you'll have linker errors.
So CMake takes care of everything automatically for you, but you need to re-generate your makefiles each time you want to toggle options on/off.
If only headers were involved and no library to link with (like some parts of the Boost framework), then yeah, defining USE_FTD2XX in your should be enough.

How to use C static libraries in D?

I'm completely stumped on how to get FreeType 2.4.8 compiled as a static lib and usable from within my D application in Windows. I've tried running it over with objconv, coff2omf, and trying extern(C)/extern(System), etc. but nothing seems to work. I'm getting symbol not found errors, access violations and just a bunch of unhelpful errors.
How can I work around this? Am I correct in using pragma lib to link to my static libraries, and how do I reliably convert COFF static libs to OMF which DMD/Optlink can use?
EDIT: Some examples of what I've tried doing:
Compiling the FreeType source with VS 2010 as a static lib, linking in my D code with pragma lib. (Returned a "library format unknown" type error)
Same as above, but converting to OMF format using objconv and then trying to link with pragma lib. (Linked successfully, but still not able to call functions.)
Compiled a DLL of the FreeType source, ran it through implib to create an import library, tried linking with pragma lib. (Linked successfully, but unable to to call any functions due to "attempt to privileged function" or "access violation" errors)
I've tried defining function prototypes as all of: extern(System), extern(C), and extern(Windows). The first and third mangle the functions names of the extern-ed functions such that they don't match the static libraries, and the second compiles, but I get access violations during runtime when I actually try and call the functions.
I'm able to get it working via dynamic libraries and symbol loading, but I'd much prefer to not require a bunch of external dependencies when deploying my project.
I'm pretty sure Derelict2 has FreeType bindings: http://www.dsource.org/projects/derelict (See DerelictFT).
Yes, you will need extern(System) in your .d files with FT function declarations.
Static library a collection of object files. So no need for any kind of conversion (omf2coff, etc). DMD accepts a static libraries as arguments, so simple dmd file1.d file2.d C:/path/to/freetype.lib should work.
Edit:
I was wrong. Apparently I needed to read some documentation about the COFF2OMF.
Quote: The Microsoft COFF format apparently changed with Visual C++ 6.0. To use coff2omf on a .lib file with the newer format, use Microsoft's linker to convert the file to the earlier COFF format:
link /lib /convert freetype.lib
So, judging by the statement above you need to perform 2 steps.
First use the Microsoft's linker to convert static library you made with the VisualStudio (in COFF format) to the old COFF format as described above.
Now execute coff2omf freetype.lib to convert the static library into the OMF format.
It should now be ready to be used with the DMD the way described originally in my post.

How are C "spec" files like this created?

How do I create foo.spec files like this one from a C header file?
i.e. I'm looking for an automated way to convert all of a header file's declarations into something simple like:
stdcall CreateFileW(wstr long long ptr long long long)
which I can easily use to perform operations later.
I realize it might not be possible for some types, but it should be possible in a large number of cases.
How do I do this?
Ok, there is the tool likely used in wine project: http://www.winehq.org/docs/winedump
Intro:
winedump is a Wine tool which aims to help:
A: Reimplementing a Win32 DLL for use within Wine, or
B: Compiling a Win32 application with Winelib that uses x86 DLLs
For both tasks in order to be able to link to the Win functions some
glue code is needed. This 'glue' comes in the form of a .spec file.
The .spec file, along with some dummy code, is used to create a
Wine .so corresponding to the Windows DLL. The winebuild program
can then resolve calls made to DLL functions.
Creating a .spec file is a labour intensive task during which it is
easy to make a mistake. The idea of winedump is to automate this task
and create the majority of the support code needed for your DLL. In
addition you can have winedump create code to help you re-implement a
DLL
Spec generation mode:
Spec mode:
<dll> Use dll for input file and generate implementation code.
....
Files output in spec mode for foo.dll:
foo.spec
This is the .spec file.
foo_dll.h
foo_main.c
These are the source code files containing the minimum set
of code to build a stub DLL. The C file contains one
function, FOO_Init, which does nothing (but must be
present).
Makefile.in
This is a template for 'configure' to produce a makefile. It
is designed for a DLL that will be inserted into the Wine
source tree.
So, winedump will dump DLL interface to SPEC file. The Spec file can be additionaly edited by hand.
And the spec describes real DLL interface, not a high-level language interface (like it is encoded in .h headers). So, you can compile your code (.h and .c and maybe something like .def to fix DLL function numbers) on win32 to DLL as usual and then dump the spec from DLL.

What libraries do I need to link my mixed-mode application to?

I'm integrating .NET support into our C++ application.
It's an old-school MFC application, with 1 extra file compiled with the "/clr" option that references a CWinFormsControl.
I'm not allowed to remove the linker flag "/NODEFAULTLIB".
(We have our own build management system, not Visual Studio's.)
This means I have to specify all necessary libraries: VC runtime and MFC.
Other compiler options include "/MD"
Next to that: I can't use the linker flag "/FORCE:MULTIPLE" and just add everything:
I'm looking for a non-overlapping set of libraries.
As a bare minimum:
mscoree.lib
MSVCRT.lib
mfc90.lib (adjust version appropriately)
And iterate from there.
Use the AppWizard to create a bare-bones MFC app in your style (SDI / MDI / dialog ) and then put on your depends.
How I solved it:
link with "/FORCE:MULTIPLE /verbose" (that links ok) and set the output aside.
link with "/NODEFAULTIB /verbose" and trace all unresolveds in the output of the previous step and add the libraries 1 by 1.
This resulted in doubles: "AAA.lib: XXX already defined in BBB.lib"
Then I finally got it:
Recompiled managed AND unmanaged units with /MD
and link to (among others):
mscoree.lib
msvcmrt.lib
mfcm80d.lib
Mixing /MT (unmanaged) and /MD (managed) turned out to be the bad idea:
different(overlapping) libraries are needed.
#ajryan: Dependcy Walker only tells me what dll's are used, not what libraries are linked to when linking.
(e.g. msvcmrt.lib ?)
I think.
Thanks for the answers!
Jan

Resources