After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 520160 - [win32] autotools-based compilation with native compiler/linker
[win32] autotools-based compilation with native compiler/linker
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-03 19:43 UTC by Edward Hervey
Modified: 2011-05-19 07:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2008-03-03 19:43:50 UTC
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.
Comment 1 Sebastian Dröge (slomo) 2008-04-13 08:15:48 UTC
1) and 2) sound more like libtool bugs, no?

For custom CFLAGS we would need a way to check with which compiler we build because if you build with cygwin you have no reason not to have unistd.h included in the parser AFAIK. So, does building with the native compilers have a special GNU target one could check for? :)
Comment 2 Edward Hervey 2008-04-13 10:15:53 UTC
tbh... the only way we can solve this issue (and dont' get me started on other platforms and toolchains) is to switch away from autotools and use a modern build system.

I've started to look at alternatives that are:
* faster
* slim dependency
* allow us to use all the detections/configuration currently existing
* not a PITA to support a new platform/arch/toolchain

Currently only waf (http://code.google.com/p/waf/) seems to be the best candidate.
Comment 3 Javier Jardón (IRC: jjardon) 2009-10-27 02:08:43 UTC
Hello Edward,

Here a list with GTK+/Gnome projects that already use waf, maybe it helps:

http://live.gnome.org/JavierJardon/NewBuildSystem

Did you consider cmake?

Regards
Comment 4 Olivier Crête 2009-10-27 09:47:23 UTC
papyon (formerly pymsn) and telepathy-butterfly used waf and it was a pita. If we really want to move off autotools (which I think are pretty much fine), then the only serious option is cmake (because KDE did all the hard work).
Comment 5 LRN 2009-10-27 13:55:12 UTC
Anyway, this bug is less relevant now, 19 months later: the process of building GStreamer with MinGW/MSys is more-or-less fixed. The only real non-trivial part is to set up MinGW/MSys, and that is being taken care of by MinGW developers (mingw-get).

Personally, i'd like to see scons being used, but that doesn't really solve the immediate problem (so you have to set up scons environment instead of msys, what's the difference?).
Comment 6 Sebastian Dröge (slomo) 2011-05-19 07:01:26 UTC
Let's close this as WONTFIX then if everything works now.