[FFmpeg-devel] [PATCH] configure: disallow OpenCL with shared libs

Michael Niedermayer michaelni at gmx.at
Wed Aug 13 01:13:35 CEST 2014


On Tue, Aug 12, 2014 at 07:31:58PM -0300, James Almer wrote:
> On 11/08/14 11:33 PM, Michael Niedermayer wrote:
> > Its API is marked as experimental, we should not export experimental API
> > from shared libs
> > 
> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > ---
> >  configure |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/configure b/configure
> > index 0ac6132..84d308e 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4861,7 +4861,9 @@ enabled opencl            && { check_lib2 OpenCL/cl.h clEnqueueNDRangeKernel -Wl
> >                                 die "ERROR: opencl not found"; } &&
> >                               { check_cpp_condition "OpenCL/cl.h" "defined(CL_VERSION_1_2)" ||
> >                                 check_cpp_condition "CL/cl.h" "defined(CL_VERSION_1_2)" ||
> > -                               die "ERROR: opencl must be installed and version must be 1.2 or compatible"; }
> > +                               die "ERROR: opencl must be installed and version must be 1.2 or compatible"; } &&
> > +                             { enabled shared &&
> > +                               die "ERROR OpenCL API is experimental and not safe to be used with shared libs"; }
> >  enabled opengl            && { check_lib GL/glx.h glXGetProcAddress "-lGL" ||
> >                                 check_lib2 windows.h wglGetProcAddress "-lopengl32 -lgdi32" ||
> >                                 check_lib2 OpenGL/gl3.h glGetError "-Wl,-framework,OpenGL" ||
> > 
> 
> The API hasn't been touched in several months and is functional, and considering 
> distros already link to opencl if available in previous ffmpeg releases, i don't 
> know if removing the feature like this is a good idea.
> Of course they can just remove this check and keep using opencl if they want to, 
> but that's besides the point.
> 
> Maybe a warning instead?

The question is if people intend to change the API and IIRC its
design makes it hard to make changes without breaking ABI

i can add a warning if preferred but i think we either should
choose to support the ABI/API until the next bump which wouldnt
need a warning or not support it in which case we probably should
disable it hard for shared libs or put a warning in the release notes
where its hard to miss

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140813/c4afb6f4/attachment.asc>


More information about the ffmpeg-devel mailing list