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 667802 - decklink: support (cross-)compilation for/on Windows using MinGW
decklink: support (cross-)compilation for/on Windows using MinGW
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.22
Other All
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-01-12 18:56 UTC by Joao Paulo Pizani Flor
Modified: 2016-12-28 11:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Joao Paulo Pizani Flor 2012-01-12 18:56:54 UTC
Hello guys and thank you very much for such an amazing project such as GStreamer.

During the last few days I have been trying to cross-compile the latest version of gst-plugins-bad using MinGW to no avail. I ran into a succession of issues, fixed by me with increasingly nastier workarounds... I am first going to give you a glimpse into my system configuration and then describe the problems I got:


Compiler: MinGW-w64 1.0+20110523-1build2-ubuntu
Host system: Ubuntu Linux 11.10
Target system: Windows 7

I have mostly been using the instructions provided here:
http://gstreamer.freedesktop.org/wiki/Win32_Cross_Compiling_With_Mingw

And these instructions are very good indeed. In fact, I have been able to compile gst-core, gst-good and gst-ugly, and I could also run simple pipelines with wine.

I only start to have problems when I try to compile gst-plugins-bad. At first, I noticed that the decklink plugin had its compilation disabled by default. Then, tinkering with autoconf.ac I "forced" HAVE_DECKLINK=yes (which I think I shouldn't have done). This because there was no windows option in a case that detected the decklink feature in autoconf.ac. Why is that?

After forcing compilation, the second problem happened: My "comutil.h" file from "/usr/i686-mingw-w64/include" caused a parse error with mingw-gcc at line 35, saying something along these lines:

"Expected type-identifier before '...' token"

The referred line contained a "throw" specifier in a function declaration with an ellipsis "...". I proceeded to EDIT comutil.h (which I know I REALLY shouldn't do) and removed the throw specifier. Then, I was faced with my last error, with which I'm struggling right now. The error is:

"In file included from gstdecklink.h:29:0,
                 from gstdecklinksrc.cpp:39:
win/DeckLinkAPI.h:19:0: warning: ignoring #pragma warning  [-Wunknown-pragmas]
gstdecklinksrc.cpp: In function 'gboolean gst_decklink_src_start(GstElement*)':
gstdecklinksrc.cpp:503:46: error: 'CreateDeckLinkIteratorInstance' was not declared in this scope"

So, there seems to a declaration missing in some header. Indeed, I found that the declaration for CreateDeckLinkIteratorInstance is present only in linux/DeckLinkAPI.h, but not in win/DeckLinkAPI.h. The implementation is in win/DeckLinkAPIDispatch.cpp - but where is the declaration in the Win case??

Please help me to fing a solution for this enigma! :)

Sorry for perhaps a superficial report, but I'll be more than happy to provide all details if someone asks for attachments...
Comment 1 Tim-Philipp Müller 2012-01-16 18:57:16 UTC
> I only start to have problems when I try to compile gst-plugins-bad. At first,
> I noticed that the decklink plugin had its compilation disabled by default.
> Then, tinkering with autoconf.ac I "forced" HAVE_DECKLINK=yes (which I think I
> shouldn't have done). This because there was no windows option in a case that
> detected the decklink feature in autoconf.ac. Why is that?

I don't know why that is, but if you run into problems after messing with configure.ac that's really not a blocker bug...

If you have any patches, we'd be happy to consider them for the release of course.
Comment 2 Joao Paulo Pizani Flor 2012-01-16 19:45:11 UTC
Good evening Tim, 

My main reason for setting this bug as "blocker" is that on previous reports here it has been said that the decklink plugin compiled OK for Windows. Furthermore, I think Windows is a significant usage scenario for the plugin, and if it does not compile under that platform, then it would be useless for a large proportion of users...

Concerning the errors themselves: as I said, I don't consider my "patch" to configure.ac as something that should be done really. It was just an attempt to forcibly enable compilation and see if there would be further errors. And there were.

I am now mainly worried about the lack of a declaration or definition for 'CreateDeckLinkIteratorInstance' in win/DeckLinkAPI.h or any equivalent file...

Thanks for your answer anyway, cheers.
Comment 3 David Schleef 2012-03-23 17:20:56 UTC
I'll probably get to this sometime soon.  I just fixed OS/X recently.
Comment 4 Joao Paulo Pizani Flor 2012-03-23 20:01:31 UTC
Good afternoon David!

I have been a bit far from the subject of this bug recently (I was working with another project at work...). 

Nevertheless in a short time (one week perhaps), I'll be again working with the decklink plugin, and will be more than happy to collaborate in solving this issue.

Thinking about it again it shouldn't be so hard to fix, so in case I succeed you guys will get my first patch to a GNOME project! Hopefully the first of a huge lot! :)
Comment 5 Tim-Philipp Müller 2016-12-28 11:57:28 UTC
Almost 5 years without activity, I assume it either works now or no one is really interested in this any more :)

Please re-open or file a new bug if it's still an issue with a current 1.x version - these plugins have changed a lot in the last few years.