[FFmpeg-devel] [PATCH] lavu: add ff_pthread_setname() and use it in various places
u at pkh.me
Sat Jan 30 17:51:37 CET 2016
On Sat, Jan 30, 2016 at 05:28:28PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 30, 2016 at 02:23:10PM +0100, Clément Bœsch wrote:
> > On Sun, Jan 24, 2016 at 07:00:30PM -0300, James Almer wrote:
> > > On 1/24/2016 6:22 PM, Clément Bœsch wrote:
> > > > On Sun, Jan 24, 2016 at 10:09:49PM +0100, Michael Niedermayer wrote:
> > > > [...]
> > > >> fails to build:
> > > >> make distclean ; ../configure --enable-pthreads --arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32 --enable-cross-compile && make -j12
> > > >> In file included from libavfilter/pthread.c:30:0:
> > > >> ffmpeg/libavutil/thread.h: In function ‘ff_thread_setname’:
> > > >> ffmpeg/libavutil/thread.h:134:5: error: implicit declaration of function ‘pthread_setname_np’ [-Werror=implicit-function-declaration]
> > > >>
> > > >
> > > > Any idea what could be the cause? Old glibc maybe?
> > >
> > > In any case, i guess the only solution would be to do a configure check
> > > like the one for pthread_cancel, or a more complete one that checks the
> > > actual signature of the function.
> > I added an extra simple check in the attached patch. I wasn't able to make
> > a more complete check (i was able to compile, link, and even execute
> > pthread_setname_np("ffmpeg") on linux).
> fails to build
> In file included from src/tests/api/api-threadmessage-test.c:29:0:
> src/libavutil/thread.h: In function ‘ff_thread_setname’:
> src/libavutil/thread.h:135:5: error: implicit declaration of function ‘pthread_setname_np’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make: *** [tests/api/api-threadmessage-test.o] Error 1
> make: *** Waiting for unfinished jobs....
> STRIP tests/checkasm/x86/checkasm.o
> STRIP libavcodec/x86/vp9itxfm_16bpp.o
> the docs say
> "These functions are nonstandard GNU extensions."
> On gnu systems they are in the libs but will only be available in the
> headers when enabled (at least it seems so here)
> i suspect the configure check does not check the headers at all
OK well fuck it. I'm dropping the patch, anyone is welcome to take over
Thanks a lot for testing.
> also isnt there a standard function to do this ?
Not that I know of, there are 4 or 5 different implementation with the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel