Dynamically link Windows DLL when no import library is available? - dll

I am just trying to integrate SDL2_mixer in a small app of mine. SDL2_mixer comes with a bunch of external modules provided as DLLs but with no import libs accompanying them. Now I am wondering how I should (dynamically) link them into my app when I cannot tell the compiler to create the required dynamic link info because I have no way to tell it about the DLL and its interface. Is there a way to accomplish that?
I was even going so far as to download the source code of the required modules (ogg, vorbis, flac, mpg123) to build the dlls myself and get the libs, but mpg123 stopped me dead in the tracks because it is totally porting unfriendly (no up to date make files for Windows, so no config.h etc. header files, hence missing type declarations and what not).
Btw, SDL2_mixer.dll (from the binaries package) doesn't come with an import lib either.

Related

CMake: how to properly distribuite CMake based libraries that will not be installed

It's said that library authors should ship their library with a config-file instead of a plain find-module.
Basically config-file are to be installed with the associated library on the system and can be used transparently by the user, whereas find-module is written by the user by his own when he finds out that the library hasn't any config-file.
But, what if I'm sure that my library will never be installed?
I'm doing embedded system development and it doesn't make much sense to install my static libraries on the system.
Different modules are organized as static libraries and handled by each project with git submodules.
Is there any way I can use config-files even in this scenario? Or, as library author, I should write a example of vanilla Find-module and say to client code "Take and copy this to your CMAKE_MODULE_PATH"?
Or maybe just tell the client code cmake to call add_subdirectory?

What should I provide in the config.cmake of my library

I have a library that I have developed and this library has some dependencies on other libraries. To be able to use this library in other projects, I need to provide a config.cmake. My question is, what do I need to put in my config.camke. Normally this config.cmake files have an INCLUDE_DIRS, LIBRARIES and EXECUTABLE variables as well as FOUND (and each one is properly set with the library, executables, and paths). However, I see that if I only give this when I try to compile the project depending on my library I get linking errors saying that the executable is missing the library that my library depends on. Is there a way that I can avoid this by doing a better config.cmake?
Thank you very much.

Building a distributable static library that uses cocoapods

I'm building a static library to be distributed to other iOS developers and having some trouble configuring the linker to allow the static library to be used in another app. I have used this guide to create a MyStaticLibrary.framework bundle containing the lib itself, and other assets such as images. This builds successfully and uses cocoapods to source the required dependencies (AFNetworking, etc.). So far, so good.
But when I import MyStaticLibrary.framework into a new Xcode project to test build an app with the library, I get tons of linker errors (Undefined symbols for architecture i386, _OBJC_CLASS_$_CLASSNAME) indicating that I'm doing something very wrong here.
So my question is, how can I build MyStaticLibrary.framework with the dependencies sourced from cocoapods, such that I can provide a 3rd party with just my framework file and allow them access to all functions specified in the public headers?
Any libraries you include using CocoaPods will not be compiled into your framework by default - they're meant to be external dependencies that are not part of your actual product. However, according to their FAQ, they support a mode where you can download pods and not have them linked to your project. From their FAQ:
Note that CocoaPods itself does not require the use of a workspace. If
you prefer to use sub-projects, you can do so by running pod install
--no-integrate, which will leave integration into your project up to you as you see fit.
To include external dependencies in your compiled binary:
For code: Instead of using cocoapods, check out the repositories you want to include and copy the source files into your project -- this will ensure they are compiled with the rest of your code
For static libraries (i.e. .a files), in your framework's Link Binary With Libraries build phase, make sure to include all the ones you would like to compile. You should also make sure the associated header files are included in Copy Headers build phase, with the appropriate visibility.
Note When bundling third party libraries in this way, you run the risk of conflicting with the projects that are integrating your framework. For example, let's say you are using a lib called SOSomeView, and you choose to compile that in with your framework. Now, if the app you are integrating with also includes SOSomeView, you will get a compile-time error that the class is declared twice. To fix this issue, you should re-namespace any external dependencies you want to hardcode into your framework (i.e. rename the class to XXSOSomeView).
I don't know how to solve that problem if you are compiling static libraries in with your framework.

Maemo / Symbian and external libraries

How can I know, whether an external library can be compiled to work on a different platform? the library for instance is tesseract-ocr
And if it possible, how do I do this?? (Basically I would like to create a Qt application that uses this library)
To find out, try building the library yourself. At the moment your question is quite broad. Post new questions when you have something more specific to ask.
If building the library fails, it is most probably due to some unsupported dependencies that you need to port first yourself.
Porting to Maemo is probably straightforward as it is a Debian-based environment and supports all the build tools such as autotools.
Symbian doesn't have autotools. Perhaps the fastest way to get started there is to first configure and build the library on e.g. cygwin and then generate the required bld.inf and .mmp files to build it on Symbian.
You can link your Qt application to regular C/C++ libraries. Just include the necessary header files in your code and link to the library using LIBS += -lfoo in your .pro file.

Creating one static library for iOS and simulator for distribution

If you create a static library for iOS do you have to distribute the header file(s) with it or is there another way to get it to work?
Currently I have a single my_lib.a file for both device and simulator but when I drag it into another test app to use it, it says it can't find the header and that all the places I'm using it in the code are undeclared. So I figure I'm either doing something wrong, or I have to also send the appropriate header files with it.
Background to my process:
I've seen two guides for creating a static library for both device and simulator. One on this site: Build fat static library (device + simulator) using Xcode and SDK 4+
and one here: http://mark.aufflick.com/blog/2010/11/19/making-a-fat-static-library-for-ios-device-and-simulator
I used the second site to just try it out. I'm also a bit curious if I did it correctly. I just went into the Release-iphone(os|simulator) folders and found the .a in the ios one and the .o in the simulator one.
The short answer is yes, you have to package header files with your static library. You have to package header files with any library in fact, dynamic or static. The library itself contains the compiled code, but you still have to tell the compiler about the identifiers in the library so when it's compiling your code it knows that they exist.
If you care, you can package your static library into a static framework with a little care. You simply create the same directory structure that a dynamic framework has, with your .a file in place of the .dylib (or .so) file. Frameworks contain a directory for headers, so you can distribute the binary and headers as a single package, and you can easily import headers from a framework without messing with the Additional Header Search Paths build setting.
Just in case it's useful - I followed Ray Wenderlich's instructions from here and was able to produce a framework for iOS that supported several architectures at once (including the simulator). The instructions are a bit too long to just copy-paste here.