../../third_party/ffmpeg/libavutil/thread.h:228:19: error: call to undeclared function 'pthread_setname_np'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 228 | ret = AVERROR(pthread_setname_np(pthread_self(), name)); | ^ m../../third_party/ffmpeg/libavutil/thread.h:228:19: note: did you mean 'pthread_set_name_np'? /usr/include/pthread_np.h:67:6: note: 'pthread_set_name_np' declared here 67 | void pthread_set_name_np(pthread_t, const char *); | ^ 1 error generated. In short, the problem seems to be that HAVE_PTHREAD_SETNAME_NP was set during the configuration phase of things instead HAVE_PTHREAD_SET_NAME_NP. In order to be able to compile, I changed lines 225 and following of third_party/ffmpeg/libavutil/thread.h to: static inline int ff_thread_setname(const char *name) { int ret = 0; pthread_set_name_np(pthread_self(), name); return ret; } Clearly not the right fix! But I'm testing right now (i.e. for at least the next couple of hours) to see if it lets me finish the compile. Perhaps an expert on the configuration phase can point me in the right direction.
The ugly fix I described does allow the compile to succeed. I assume no one else has run into this? (I should have mentioned that I am one of those poudriere spurners who uses portmaster.)
Created attachment 250204 [details] Ugly fix reformatted as a proper patch May the spirit of Ada Lovelace forgive me; I have turned my disgusting fix into a patch. I verified that the fix allows my compile to complete and that the resulting build indeed operates the way you would expect a web browser to operate. I'm in the process of doing a proper portmaster build (no, that's not a contradiction in terms) just to verify that I didn't screw something up. Meanwhile, I hope someone figures out the correct fix.
P.S. My sincere appreciation to whomever came up with the one thousand two hundred and eighty-five (!!) patches already in this package to enable chrome to be built and used on FreeBSD!.
Created attachment 250208 [details] Correctly formatted ugly patch I formatted the patch wrong. Corrected with new attachment.
Still trying to figure out the right way to fix this bug. There are forty-two files names 'config.h' under work/chromium-124.0.6367.60 that #define HAVE_PTHREAD_SET_NAME_NP, and they all assert "/* Automatically generated by configure - do not modify! */". Forty of them #define HAVE_PTHREAD_SET_NAME_NP 0 and the other two define it to 1. Clearly for FreeBSD it should always be one. But I have no idea where the configure script that generates these config.h files is to be found, and so I can't tell why HAVE_PTHREAD_SET_NAME_NP is set wrongly. Is it possible these config.h files are in the distfiles, having already been generated?
I'm running into this problem too :) I am still still :) using 12.4-STABLE and thought it was due to the version being out of support, but it is not. It seems possible that this could also happen in 14.0-RELEASE. #define HAVE_PTHREAD_SET* seems to have added from chromium-124.0.x.x. FreeBSD has pthread_setname_np in <pthread.h>. But it is between #if__BSD_VISIBLE and #endif. <sys/cdefs.h> could cause __BSD_VISIBLE to be 0 if -std=c99 or -std=c11? is present. FreeBSD also has pthread_set_name_np in <pthread_np.h>. So the correct answer for FreeBSD is the following. #define HAVE_PTHREAD_SET_NAME_NP 1 #define HAVE_PTHREAD_SETNAME_NP 0 www/chromium creates and uses the following config.h at build time. (ARCH=amd64) ${WRKSRC}/third_party/ffmpeg/chromium/config/Chrome/freebsd/x64/config.h The file has them both as 1. HAVE_PTHREAD_SETNAME_NP may need to be set to 0.
(In reply to Tatsuki Makino from comment #6) Thank you! This surely sounds like where the real problem is, and I will try it on my machine in the morning (it's bed time for me right now). I was hoping someone would come up with a less monstrous fix than the one I proposed. Thanks again!
${WRKSRC}/third_party/ffmpeg/BUILD.gn has -std=c99. I guess we need to pass cflags+=-std=c99 in some way to ${WRKSRC}/third_party/ffmpeg/chromium/scripts/build_ffmpeg.py running on the pre-configure target.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=9fa5ded7494b548e2aca67bc839845d68604758f commit 9fa5ded7494b548e2aca67bc839845d68604758f Author: Robert Nagy <rnagy@FreeBSD.org> AuthorDate: 2024-04-25 07:50:04 +0000 Commit: Robert Nagy <rnagy@FreeBSD.org> CommitDate: 2024-04-25 07:50:04 +0000 www/*chromium: check for non-portable pthread functions in pthread_np.h only PR: 278560 .../files/patch-third__party_ffmpeg_configure (new) | 13 +++++++++++++ .../files/patch-third__party_ffmpeg_configure (new) | 13 +++++++++++++ 2 files changed, 26 insertions(+)
A commit in branch 2024Q2 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=bc43faef5fc5d7e7bf0f89c7bcdcbb94dd683ef6 commit bc43faef5fc5d7e7bf0f89c7bcdcbb94dd683ef6 Author: Robert Nagy <rnagy@FreeBSD.org> AuthorDate: 2024-04-25 07:50:04 +0000 Commit: Robert Nagy <rnagy@FreeBSD.org> CommitDate: 2024-04-25 07:50:50 +0000 www/*chromium: check for non-portable pthread functions in pthread_np.h only PR: 278560 (cherry picked from commit 9fa5ded7494b548e2aca67bc839845d68604758f) .../files/patch-third__party_ffmpeg_configure (new) | 13 +++++++++++++ .../files/patch-third__party_ffmpeg_configure (new) | 13 +++++++++++++ 2 files changed, 26 insertions(+)
Well, at least I'm not the only one working on this in the middle of the night! My sincere thank you to Robert Nagy and Tatsuki Makino for getting this debugged! Are we the only three people who ran into this problem? Does it not occur when building with poudriere?
(In reply to George Mitchell from comment #11) You only run into this when building with >=clang18 because a warning has been upgraded to an error. The warning was there already and the definition of pthread_setname_np in pthread.h on FreeBSD is quiet wrong IMHO. It should have been placed into pthread_np.h. But meh.