GNOME Bugzilla – Bug 733788
Build failure QtGStreamer on Windows
Last modified: 2018-01-23 20:44:16 UTC
Created attachment 281774 [details] [review] Patch file I attempted to build the latest QTGStreamer (1.2.0) on Windows (using VS2010 against QT5.3). This worked, but 3 small changes were needed: 1. I had to delete the header file <Memory>, as this conflicted with the CRT's <memory>, due to Windows being case insensitive. 2. In gstqtglvideosinkbase, I renamed a local variable from interface to iface to avoid a compile error. 3. I added an option in cmake to set the CMAKE_LIBRARY_PATH so that the path to the Windows SDK can be specified in the CMake-GUI. I am now able to compile QTGStreamer and have built a simple proof of concept application. I have attached a patch with the changes I made to my local copy.
(In reply to comment #0) > 1. I had to delete the header file <Memory>, as this conflicted with the CRT's > <memory>, due to Windows being case insensitive. This sucks. This is not acceptable as a patch for QtGStreamer in general, so there needs to be another solution. One possible solution would be to stop creating manually the camel-case headers and generate them from cmake *after* the build, just for installing them. That would need some trickery, though, to get the examples and tests working in-tree (they should not use the lower-case headers). > 2. In gstqtglvideosinkbase, I renamed a local variable from interface to iface > to avoid a compile error. I don't see why this would be an error, but the patch doesn't hurt. I can commit that part. > 3. I added an option in cmake to set the CMAKE_LIBRARY_PATH so that the path > to the Windows SDK can be specified in the CMake-GUI. This doesn't belong in QtGStreamer imho. CMAKE_LIBRARY_PATH is a standard cmake option, like CMAKE_PREFIX_PATH and others. If you would like to have it in cmake gui, then perhaps you could file a feature request for cmake. Typically this is specified on the command line, either as an environment variable or as a cmake variable.
(In reply to comment #1) > One possible solution would be to stop creating manually the camel-case headers > and generate them from cmake *after* the build, just for installing them. That > would need some trickery, though, to get the examples and tests working in-tree > (they should not use the lower-case headers). Another way might be to move the camel-case headers to a separate directory in the tree, such that even within the tree they always have to be referred to by their fully qualified name i.e. <QGst/Memory>, in that example. What do you think? > > 2. In gstqtglvideosinkbase, I renamed a local variable from interface to iface > > to avoid a compile error. > > I don't see why this would be an error, but the patch doesn't hurt. I can > commit that part. Thanks. Some compiler options on windows make 'interface' a reserved word, though I'm surprised that the build is using any of these options. I didn't investigate in detail as the fix was quick and obvious. I can look again later, once we've solved the naming conflict with the memory header file. > This doesn't belong in QtGStreamer imho. CMAKE_LIBRARY_PATH is a standard cmake > option, like CMAKE_PREFIX_PATH and others. If you would like to have it in > cmake gui, then perhaps you could file a feature request for cmake. Typically > this is specified on the command line, either as an environment variable or as > a cmake variable. Yes, agreed, there are other ways of achieving the same thing.
It looks like this (memory header file) is basically same as bug #763201. There's a fix there too.
FWIW I think I like the solution in bug #763201 better. This does seem like a duplicate Renaming Memory to QGstMemory. It is a bit ugly in that it generates paths QGst/QGstMemory, but at least it doesn't collide.
*** This bug has been marked as a duplicate of bug 763201 ***