[gstreamer-bugs] [Bug 492077] Build issues on Windows/MSVC

Wed Oct 31 18:29:26 PDT 2007

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=492077

  GStreamer | gstreamer (core) | Ver: 0.10.14

Ole André Vadla Ravnås changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

------- Comment #7 from Ole André Vadla Ravnås  2007-11-01 01:29 UTC -------
Sorry about the hassle with the .def stuff, my bad for not getting around to
pushing the patches earlier. The change of alphabetical order was clearly not
intentional, I realize that this must've been done rather hastily.
I'm planning on going over this properly with the same code built with
autotools on Linux, run nm, sort the symbols and compare to an export dump on
Windows. There's probably a few left out, the ones added by the patch were
discovered because some plugin relied on it, and given that we only build a
subset of the plugins there could be a few still left out.  Maybe this is
something that could be integrated with the continuous build system, after
building it could dump the symbols and compare to the .def files.

Great catch regarding the HAVE_UNISTD_H fix, that's definitely more correct.

Patch #98238 is in retrospect a bit confusing and needs some explaining. When
exporting symbols you need to explicitly say which should be exported, or you
won't get any exported at all. There are two ways to do this.

1. You have an entry like the following in the header-file:

int __declspec(dllexport) gst_foo_do_bar (void);

(Obviously the _user_ of the library needs "dllimport" instead of "dllexport",
so you want to use a macro for the whole __declspec(dllimport/dllexport).)

2. Tell the linker to use a .def file that you create with a list of symbols,
like:

gst_foo_do_bar

A common convention is to have a define called "LIBRARY_NAME_EXPORTS" that you
only define when building LIBRARY_NAME, and in the header-file you do:

#ifndef __GNUC__
# define __DLL_IMPORT__ __declspec(dllimport)
# define __DLL_EXPORT__ __declspec(dllexport)
#else
# define __DLL_IMPORT__ __attribute__((dllimport)) extern
# define __DLL_EXPORT__ __attribute__((dllexport)) extern
#endif

#if defined(__WIN32__) || defined(_WIN32) || defined(WIN32)
# ifdef LIBRARY_NAME_EXPORTS
#  define LIBRARY_NAME_API      __DLL_EXPORT__
# else
#  define LIBRARY_NAME_API      __DLL_IMPORT__
# endif
#else
# define LIBRARY_NAME_API       extern
#endif

And use the LIBRARY_NAME_API like this:

int LIBRARY_NAME_API gst_foo_do_bar (void);

GStreamer has, as you can see from the patch, a mixture of these two (but the
majority is of the latter kind). The upside to the .def approach is that you
don't need to change all the header-files if you're porting something to
Windows, whilst the flip side is obviously that you need to maintain the .def
files.

The patch changes the macro GST_DEBUG_CATEGORY_EXTERN so that it declares the
symbol as exported when used by a plugin (built with GST_PLUGIN_EXPORTS
defined) to export a debug category, and imported otherwise. Without this patch
the linker generates warnings about conflicting linkage, but presumably it
figures out what your intention is and does the right thing.

When building GStreamer on Windows we have a bunch of MSVS2005 project files of
which those for plugins define GST_PLUGIN_EXPORTS. I didn't add this to the
project files in the win32 subdirectory because I wouldn't be able to test
these changes.

The reason that we're not using these project files is another (rather long)
story, but basically it's because we have a different approach. MSVS has the
notion of a solution containing projects, where each project is typically a
program or a library. The solution also knows about dependencies between the
projects. In our team we have one big solution that contains projects for
everything from GLib to GStreamer (as this is the most comfortable to work with
for a Windows developer, given that dependencies etc. are taken care of), and
by using something called "property sheets" we can share common things among
the projects. All projects inherit the property sheet that we've called
"Common" which sets output directories, common compiler flags etc., and the
projects that are GStreamer plugins also inherit "GStreamerPlugin", which
overrides the output directory to be $(OutDir)/lib/gstreamer-0.10 instead of
the default $(OutDir)/bin (set by the Common property sheet), adds this
GST_PLUGIN_EXPORTS define, etc. We also have a python tool that parses a given
Makefile.am and installs header-files in $(OutDir)/include, so that we don't
have to duplicate the list of header-files in our build system.  So bottom line
is that we end up with just the list of files in the project files, they end up
being really slim thanks to property sheets, and with one toplevel solution
instead of one solution per component, so that means we have very little in
common with the projects in the win32 subdir.
I'm hoping that this is something that can be made suitable for upstream
eventually, but that's a different issue (something that I'm planning on trying
to address in http://projects.collabora.co.uk/~oleavr/OABuild/).

Sorry about the lengthy explanation. Coming from a Linux-background I have to
say that the more I learn about Windows the more it beats me that it is not a
very developer-friendly platform. :)

-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=492077.