taglib on windows with visual studio
roel_v at stack.be
Tue Jul 12 00:37:04 CEST 2005
I've been trying to get taglib to compile with MS Visual Studio (version
.Net 2003). My goal was to not have to make any changes to the taglib
sources but unfortunately I cannot seem to find a way to get that done.
I did manage to get the sample running but the problems I encountered
were as follows:
- There is no unistd.h on windows. That wasn't too bad, I just created a
subdirectory 'win32' in the sources (at the root level of the tarball)
and placed a file called unistd.h there, with the following content:
const W_OK = 2;
const R_OK = 4;
#define access _access
#define ftruncate _chsize
The last two defines are to cater for the different names of those two
functions on windows.
- The config.h file is missing. On Unix it is of course generated by the
autotools but I didn't want to use Cygwin. I made an empty config.h
file, all I could see in the sources was that the file is used to check
whether or not zlib support should be compiled in. So for now I've
disabled that, it's easy to add support for it.
- The taglib source is organized so that it expects every directory to
be present in the include search path. (-I on gcc). This is a pita; I
had to add every directory to the project file (I didn't want to resort
to command line builds). Is there a reason for this behaviour? I've seen
it mentioned in the docs, as well as the included tool for listing all
the directories, but I don't see the use of it. If it's to allow easy
reorganization of the source files: how often does that happen? And if
it must happen, it can't be more than 15 minutes work to change relative
- Then finally, the biggest problem. Because of the license of taglib I
needed to compile it as a dll. But on windows for the creation of dlls,
one needs to mark all symbols to be exported with __declspec(dllexport).
This requires modifying the taglib sources. So I tried to circumvent it
by trying to use Cygwin's dlltool and dllwrap to create the .lib file.
I've tried all sorts of combinations of command line options and I
succeeded in getting the tagreader sample to compile and link with a
.lib generated by dlltool, but the testprogram would crash right after
startup. If someone knows a way to generate a .exp file (or .lib) from a
.dll and/or .map file, please let me know.
Anyway since I couldn't get it work I've resorted to adding a macro to
the taglib sources:
#define TAGLIB_EXPORT __declspec(dllexport)
#define TAGLIB_EXPORT __declspec(dllimport)
and then add TAGLIB_EXPORT to the classes that need to be exported, as such:
class TAGLIB_EXPORT String
Now I have the tagreader.cpp sample running. (but only with the
single-threaded runtime dlls, but that's ok for now).
Now I would still like a solution where I don't have to create my own
version of taglib every time a new version comes out. Options are:
- A change of the taglib license to allow static linking without
requiring the main application to be LGPL/GPL. That would make static
linking a viable option for me, but it's probably not an option for the
authors of this fine library :)
- Finding a tool that will allow generation of .libs from dlls without
exported symbols. Don't know if it's possible.
- Add the above-mentioned macros to the source code. It would add around
20 or so lines of macro code. I don't know what the standpoint of the
taglib author is on this? It wouldn't require much maintenance and would
be very unobstrusive; in addition to the macros there would only be one
new toplevel directory with the Visual Studio project files for the
library and the samples and the unistd.h and config.h files.
Failing this I'm willing to create a version of taglib that has the
above changes and provide dll's on my own website, but of course if at
all possible I'd like to avoid the work.
This mail is probably getting way too long so I'll cut it off; are there
any other VS users on this list who have any ideas or opinions on the
points I raised?
More information about the taglib-devel