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 593688 - effectv can no longer be compiled with gcc 3
effectv can no longer be compiled with gcc 3
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 0.10.17
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-31 15:50 UTC by Peter Kjellerstedt
Modified: 2009-11-20 00:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Allow effectv to be compiled with gcc 3 again (7.83 KB, patch)
2009-08-31 15:50 UTC, Peter Kjellerstedt
committed Details | Review
Patch for MSVC compatibility (1.34 KB, patch)
2009-11-17 22:01 UTC, David Hoyt
none Details | Review
Patch for effectv (9.20 KB, patch)
2009-11-17 22:36 UTC, David Hoyt
none Details | Review

Description Peter Kjellerstedt 2009-08-31 15:50:55 UTC
Created attachment 142138 [details] [review]
Allow effectv to be compiled with gcc 3 again

Recent changes in gst-plugins-good/gst/effectv prevents it from being compiled
with gcc 3. The problem is that the new code uses preprocessor conditionals
within a macro call which does not work with older versions of gcc. See the
attached patch for a suggested solution to the problem.
Comment 1 Sebastian Dröge (slomo) 2009-08-31 16:11:47 UTC
commit fbefd9c66623b3f6e967aa52c6de270dbd368011
Author: Peter Kjellerstedt <pkj@axis.com>
Date:   Mon Aug 31 18:10:11 2009 +0200

    effectv: Fix compilation with gcc 3
    
    Recent changes in gst-plugins-good/gst/effectv prevents it from being compil
    with gcc 3. The problem is that the new code uses preprocessor conditionals
    within a macro call which does not work with older versions of gcc.
    
    Fixes bug #593688.
Comment 2 David Hoyt 2009-11-17 22:00:53 UTC
This introduced a compiler error in MSVC. Please see the attached patch for a fix that should work.
Comment 3 David Hoyt 2009-11-17 22:01:30 UTC
Created attachment 147995 [details] [review]
Patch for MSVC compatibility
Comment 4 David Hoyt 2009-11-17 22:36:16 UTC
Created attachment 147997 [details] [review]
Patch for effectv
Comment 5 Sebastian Dröge (slomo) 2009-11-18 07:08:48 UTC
That patch doesn't apply cleanly to latest GIT. Could you rebase it please? Also it would be nice if you could attach it in git format-patch format :)
Comment 6 Tim-Philipp Müller 2009-11-18 08:31:13 UTC
Also, it seems to me that one could simplify this a lot with one or two common defines for the caps / template caps, instead of having ifdef else blocks everywhere.
Comment 7 Peter Kjellerstedt 2009-11-18 12:12:06 UTC
Well, David's patch seems to totally disregarded my patch, which has already been applied. 

If there is some common effectv include file, then a common macro or two would probably make things more readable.
Comment 8 David Hoyt 2009-11-18 17:39:52 UTC
The reason I had to create this patch was because of Peter's patch.

The point was that msvc for whatever reason didn't like the compiler directives inside the function declaration. I'm not sure why that was and I agree that my patch isn't the best way - but it worked.

I could use the community's help in providing a better method for accomplishing the same idea.
Comment 9 Tim-Philipp Müller 2009-11-18 17:59:12 UTC
(In reply to comment #4)
> Created an attachment (id=147997) [details] [review]
> Patch for effectv

Actually, I'm a bit confused now. It looks like this patch was created against an effectv version from before Peter's patch was applied. And it seems like Peter's patch was basically for the same issue (and what I was suggesting above).
Comment 10 David Hoyt 2009-11-18 18:01:34 UTC
Please see my comment above yours -- Peter's patch introduced a compile error with msvc. My patch should make gcc and msvc happy, but it may not be the best way to do it.
Comment 11 David Hoyt 2009-11-18 18:04:25 UTC
It's a patch against the gst-plugins-good 0.10.17 release, which includes Peter's patch. I submitted it to say that the fix provided in this bug report actually introduced other, related errors.

Perhaps I should have filed a new bug report to make this less confusing.
Comment 12 Peter Kjellerstedt 2009-11-18 18:09:28 UTC
Your patch cannot possibly be against 0.10.17, or at least not against the 0.10.17 version that is tagged in git... The "old code" in you patch does not match what is in 0.10.17 (it does, however, match what was in 0.10.16...)
Comment 13 David Hoyt 2009-11-18 18:10:50 UTC
My apologies - let me check then and get back to this.
Comment 14 Tim-Philipp Müller 2009-11-20 00:12:35 UTC
Closing this again. Please file a new bug or re-open if you still have problems with -good 0.10.17.