ansaurus

Question

Compiling static TagLib 1.6.3 libraries for Windows

Answer 1

+1 A:

Since Mac works for you, I'm just talking about Win32.

Ok, this are my Taglib.pro and an excerpt of my project.pro: https://gist.github.com/449ea81ce92f52399f41. Check them out. My Taglib may be a bit outdated, so take care, some files you may have could be missing there. Also take care of the relative paths. They are all relative to the .pro file.

I just ran cmake . inside the taglib directory. This should result in a config.h and a taglib_config.h

You definitly only need the libTaglib.a when you use QtCreator and mingw-gcc. *.lib are MSVC specific!

Wolfgang Plaschg 2010-10-07 09:35:45

This is great information to have, thanks. In the past I have been smashing all the *.h files into one directory for my INCLUDEPATH to make it easier to manage. Is this incorrect? Also I haven't been including DEPENDPATH because I didn't know I needed it.

jocull 2010-10-07 13:29:59

To be honest I'm not sure if you need DEPENDPATH, but it doesn't hurt either. Since TagLib itself relies on proper Include Paths smashing all .h files into one directory is not a good idea but not the source of your linker problem!

Wolfgang Plaschg 2010-10-07 13:48:26

Im not 100% sure about this: You're compiling TagLib as a shared library, but your linker complains about some symbols. Make sure your linker does know that the symbols from TagLib are _dynamically_ loaded, not _statically_! Make sure you **don't** have defined `TAGLIB_STATIC` **nor** `MAKE_TAGLIB_LIB` when compiling your program. Read `taglib_export.h` carefully as this file is the pivotal point for exporting or importing symbols.

Wolfgang Plaschg 2010-10-07 13:52:52

Just so I understand this, I **do** want to compile TagLib statically, but when I am compiling my program TagLib is now considered a **shared** resource. Is that correct?

jocull 2010-10-07 15:21:20

Do you have any efficient methods that you use to export all the *.h files in their current directory structures? It's a mess the way it is currently.

jocull 2010-10-07 15:23:49

When you create a .dll and a .a file you create a **shared** resource. To link TagLib statically (ie. directly) into your binary, just add TagLib's sources to your .pro file (with `SOURCES`) and define `TAGLIB_STATIC`.

Wolfgang Plaschg 2010-10-07 17:08:22

Ok, that clarifies, thanks. In that case, I'm currently working with a **shared** TagLib build. I actually got it to build with Qt (finally) and I have it configured like you showed. I have everything compiling with no errors, but once I run I get an error immediately: QtTrayTime.exe exited with code -1073741515 ... From the Googling I've done I'm assuming this means that I did something wrong with linking my shared library. I made a Gist of what I have currently: http://gist.github.com/615451

jocull 2010-10-07 18:07:25

Glad to hear that. Try to copy `TagLib.dll` into the same directory as your QtTrayTime.exe.

Wolfgang Plaschg 2010-10-07 23:15:06

AHHHH IT WORKS! You are the best man, thanks so much for all of your help. This has been the bane of my existence for days. I should have thought of that (it's what you have to do in C#) but this C++ stuff is throwing me for a loop pretty hard. Can you explain to me why since we define things like win32:LIBS += why I have to manually copy the DLL? Is the LIBS += just for the compiler's use, but I have to manually copy the DLL for the .exe's use? Why isn't it like this on Mac?

jocull 2010-10-08 13:34:53

Thanks to your help I was also able to statically compile the TagLib source files into my project. It was as easy as adding the *.h and *.cpp files to my project and adding DEFINES += TAGLIB_STATIC=1. I also copied over the FRAMEWORK_HEADERS and QMAKE_BUNDLE_DATA for Mac from the original TagLib *.pro. Thanks again!

jocull 2010-10-08 18:00:32

ansaurus

tags:

views:

answers:

Compiling static TagLib 1.6.3 libraries for Windows

related questions