[gstreamer-bugs] [Bug 520160] New: [win32] autotools-based compilation with native compiler/linker

[GStreamer (bugzilla.gnome.org)]

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=520160

  GStreamer | gstreamer (core) | Ver: HEAD CVS
           Summary: [win32] autotools-based compilation with native
                    compiler/linker
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: bilboed at bilboed.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


The current win32 build system for GStreamer doesn't allow you to configure
gstreamer to one's needs (ex : use the binary registry, or disable some
features) since it doesn't use autotools/configure to build  it.

After a few days of banging my head at it, it IS possible to build gstreamer on
win32 using autotools AND the native compiler/linker (cl.exe, link.exe), under
cygwin/mingw32 and producing native binaries (usable outside of
cygwin/mingw32/msys)... but is not trivial.

This bug-report is to aggregate all issues with the buildchain and find
solutions to those issues.

This bug is NOT about bugs in the code but about the build process, separate
bugs will be open regarding bugs in the code when using native compiler.

What doesn't work:
(1) libtool is confused about how to handle this toolchain (cygwin + native
compiler/linker):
 ** It doesn't know how to convert "-L/some/path/ -lalib" to
"c:/windowsy/some/path/libalib.lib" when linking, it currently converts it to
"/usr/bin/libalib.dll" (wrong path, wrong extension)
 ** It doesn't know how to convert .la dependencies into the location to the
proper .lib for the linker (used for example in libs/ and plugins/ for linking
against locally built libgstreamer/libgstbase).
 ** It doesn't know how to created a .def file for the linker (needed for
exporting the symbols) using the list of symbols to export contained in .exp.
 ** It doesn't know

(2) ar is broken when it comes to handling archives not in the current
directory, which means using libgstparse.la when linking gst/libgstreamer
doesn't work

(3) In order to produce debug builds, you need to add "-Zi" to both the CFLAGS
and linker parameter

(4) In order to produce portable binaries/libraries that don't depend against a
specific version of the CRT, you need to add the following flag to compiler and
linker:
 ** -MT (for non-debug builds)
 ** -MTd (for debug builds)

CFLAGS needed to compile the code:
* -DYY_NO_UNISTD_H : needed for libgstparse
* -D_CRT_SECURE_NO_WARNINGS : CRT has new "more secured" versions of several
basic functions, with this flag it will allow gstreamer to be built with the
common versions (more info here :
http://msdn2.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx)
* -DWIN32 -DHAVE_WIN32 -D_WINDOWS : Needed for gstreamer dependencies include
files.


-- 
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=520160.