Created attachment 251083 [details] poudriere build log I started getting the error compiling chromium 125.0.6422.76_1, which is kept persistent with update to 125.0.6422.112: In file included from ../../third_party/sqlite/sqlite3_shim.c:16: ../../third_party/sqlite/src/amalgamation/sqlite3.c:53619:21: error: call to undeclared function 'alloca'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 53619 | u32 *aiValues = sqlite3StackAllocRaw(0, sizeof(p->u.aHash)); | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:20536:38: note: expanded from macro 'sqlite3StackAllocRaw' 20536 | # define sqlite3StackAllocRaw(D,N) alloca(N) | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:53619:10: error: incompatible integer to pointer conversion initializing 'u32 *' (aka 'unsigned int *') with an expression of type 'int' [-Wint-conversion] 53619 | u32 *aiValues = sqlite3StackAllocRaw(0, sizeof(p->u.aHash)); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ all seemingly related to alloca(). I am not sure when did that started, might be with an update of llvm18. Even more, I am not sure if this is a local issue or indeed a port's problem. The poudriere log is attached.
I'm getting this error too. Not sure when it was introduced because it was masked by other config and build errors since 125.0.6422.76. This is on 14.0-RELEASE with a base compiler of clang 16.0.6, at least the log says "c++" without any indication of the llvm18 in dependencies. I've seen this error before in other ports with internal sqlite, there it happened when the config header for sqlite wasn't adapted properly to FreeBSD. The alloca function needs an additional header include, in contrast to Linux. If I remember correctly there is a define for it somewhere in the config.
Mixed that up, sorry: Linux has an alloca.h header which FreeBSD has not (defined in stdlib.h). The relevant SQLite config is SQLITE_USE_ALLOCA, and in devel/qtcreator where I had similar problems I just disabled that. This may not be the best solution here, since alloca has an impact on runtime efficiency. We may have to #include "stdlib.h" somewhere.
As a preface, I am encountering this problem in 12.4-STABLE amd64 environment :) But I'm writing this while looking at the <stdlib.h> for 14.1-STABLE. It seems that if <stdlib.h> is used with __BSD_VISIBLE defined, alloca will become a __builtin_alloca. If the C version is strict, sys/cdefs.h will set the __BSD_VISIBLE to 0. First of all, this seems to be the cause of the inability to use alloca.
The reason why alloca is not defined is likely to be the following part. # 14123 "../../third_party/sqlite/src/amalgamation/sqlite3.c" #define _XOPEN_SOURCE 600 This defines _POSIX_C_SOURCE and makes __BSD_VISIBLE completely undefined. Line 14123 of ${WRKSRC}/third_party/sqlite/src/amalgamation/sqlite3.c reads as follows /* ** We need to define _XOPEN_SOURCE as follows in order to enable ** recursive mutexes on most Unix systems and fchmod() on OpenBSD. ** But _XOPEN_SOURCE define causes problems for Mac OS X, so omit ** it. */ #if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && !defined(__APPLE__) # define _XOPEN_SOURCE 600 #endif
(In reply to Tatsuki Makino from comment #4) You're right, I've read that code multiple times before I spotted the #else, but with _XOPEN_SOURCE defined there is neither __BSD_VISIBLE nor alloca. And this is correct I think, according to standards _POSIX_C_SOURCE and _XOPEN_SOURCE actually *restrict* the set of available headers and functionality. See: https://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html Which means _XOPEN_SOURCE should never be set if non-standard functionality like alloca (or BSD, GNU extensions) is used. Add the maintainer of databases/sqlite3 to this discussion, I think SQLITE_USE_ALLOCA is disabled there as well?
I'm currently experimenting with the internal SQLite of devel/qtcreator, which is easier to test for me. Appending " && !defined(__FreeBSD__)" to the exceptions for APPLE and DARWIN works, but I think the correct solution for upstream should be: #if defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE) # define _XOPEN_SOURCE 600 #endif Rationale is that _XOPEN_SOURCE helps to extend an already present restriction to _POSIX_C_SOURCE with XOPEN features. But SQLite should not impose a restriction to XOPEN features only when there is no POSIX restriction in effect, thereby reducing the available feature set (like alloca). I don't have time to create a chromium patch now, it may be defined in multiple places due to the amalgamated SQLite source.
Created attachment 251127 [details] ad-hoc patch for www/chromium I don't think we should do it like this patch :), but I think it will workaround it on operating systems where FreeBSD and __FreeBSD__ is defined. Please note that this patch has only been written, and the actual build has not yet been done.
Trying the ad-hoc patch now; should know if it works in a few hours. Thanks, Tatsuki Makino!
Should have noted: I'm on 13.2-RELEASE-p10.
(In reply to Tatsuki Makino from comment #7) My compile using this patch is past the point of the error, so the patch does work. I just recompiled databases/sqlite3 to see what I could find out about SQLITE_USE_ALLOCA there. It doesn't seem to use that option. So it seems plausible to me that it's not a good idea for www/chromium either. How it gets turned on for chromium is above my pay grade, but wherever that is is probably the place to fix this bug.
Created attachment 251173 [details] Build www/chromium with proposed upstreamable fix. Fix the build as explained in previous comment, that may be upstreamable to SQLite proper. Build is still running, but past the error with sqlite3_shim.c. I tested the same fix with the internal SQLite of devel/qtcreator, no regressions found. Will be testing chromium with this fix tomorrow.
(In reply to George Mitchell from comment #10) I'd like to hear from the maintainer about this. Could well be that SQLITE_USE_ALLOCA was just disabled in databases/sqlite3 because of the issue with _XOPEN_SOURCE outlined above. That should be fixed upstream. In cases like SQLite with many temporary allocations alloca() is a nice optimization, and in my experience alloca() works fine on FreeBSD.
I cannot reproduce this on 13.3/amd64 so I assume this happens due to some header poisoning from some dependencies. Anyone who can reproduce this 100%, please try to remove patch-third__party_sqlite_BUILD.gn first.
(In reply to Robert Nagy from comment #13) Removing the patch third__party_sqlite_BUILD.gn did not changed the outcome. The build still fails with the same alloca() errors from sqlite3_shim.c.
(In reply to Florian Walpen from comment #12) If that is to be upstreamed the comment needs to be fixed up as well.
On FreeBSD 14p6 : [root@marietto /usr/ports/www/chromium]==> MAKE_JOBS_UNSAFE=yes make -m64 -msse3 -Xclang -fdebug-compilation-dir -Xclang . -no-canonical-prefixes -ftrivial-auto-var-init=pattern -O2 -fdata-sections -ffunction-sections -fno-unique-section-names -fno-math-errno -fno-omit-frame-pointer -g0 -fprofile-use=../../chrome/build/pgo_profiles/chrome-linux-6422-1715686914-39d3c200676449e33ad84989ea45ad3474fab6e2-013ab7d1275249b95c27d77aaaa0d257ac6d2359.profdata -Wno-profile-instr-unprofiled -Wno-profile-instr-out-of-date -Wno-backend-plugin -mllvm -enable-ext-tsp-block-placement=1 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -Wall -Wno-unused-variable -Wno-c++11-narrowing -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -Wloop-analysis -Wno-unneeded-internal-declaration -Wno-cast-function-type -Wno-ignored-pragma-optimize -Wno-deprecated-builtins -Wno-bitfield-constant-conversion -Wno-deprecated-this-capture -Wno-invalid-offsetof -Wno-vla-extension -Wno-shadow -Wno-unused-function -isystem/usr/local/include -isystem/usr/local/include -std=c11 -c ../../third_party/sqlite/sqlite3_shim.c -o obj/third_party/sqlite/chromium_sqlite3/sqlite3_shim.o In file included from ../../third_party/sqlite/sqlite3_shim.c:16: ../../third_party/sqlite/src/amalgamation/sqlite3.c:53619:21: error: call to undeclared function 'alloca'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 53619 | u32 *aiValues = sqlite3StackAllocRaw(0, sizeof(p->u.aHash)); | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:20536:38: note: expanded from macro 'sqlite3StackAllocRaw' 20536 | # define sqlite3StackAllocRaw(D,N) alloca(N) | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:53619:10: error: incompatible integer to pointer conversion initializing 'u32 *' (aka 'unsigned int *') with an expression of type 'int' [-Wint-conversion] 53619 | u32 *aiValues = sqlite3StackAllocRaw(0, sizeof(p->u.aHash)); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../third_party/sqlite/src/amalgamation/sqlite3.c:78371:14: error: call to undeclared function 'alloca'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 78371 | b.apCell = sqlite3StackAllocRaw(0, szScratch ); | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:20536:38: note: expanded from macro 'sqlite3StackAllocRaw' 20536 | # define sqlite3StackAllocRaw(D,N) alloca(N) | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:78371:12: error: incompatible integer to pointer conversion assigning to 'u8 **' (aka 'unsigned char **') from 'int' [-Wint-conversion] 78371 | b.apCell = sqlite3StackAllocRaw(0, szScratch ); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../third_party/sqlite/src/amalgamation/sqlite3.c:166054:12: error: call to undeclared function 'alloca'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 166054 | pSpace = sqlite3StackAllocRawNN(pParse->db, nSpace); | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:20537:38: note: expanded from macro 'sqlite3StackAllocRawNN' 20537 | # define sqlite3StackAllocRawNN(D,N) alloca(N) | ^ ../../third_party/sqlite/src/amalgamation/sqlite3.c:166054:10: error: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion] 166054 | pSpace = sqlite3StackAllocRawNN(pParse->db, nSpace); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6 errors generated. ninja: build stopped: subcommand failed. *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/chromium *** Error code 1 Stop. make: stopped in /usr/ports/www/chromium
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4ba66b974729b45f6c2418d87d7403ef2e7b474d commit 4ba66b974729b45f6c2418d87d7403ef2e7b474d Author: Robert Nagy <rnagy@FreeBSD.org> AuthorDate: 2024-06-03 12:52:56 +0000 Commit: Robert Nagy <rnagy@FreeBSD.org> CommitDate: 2024-06-03 12:54:46 +0000 www/*chromium: update to 125.0.6422.141 Additionally to the update, do not define _XOPEN_SOURCE on FreeBSD either in the internal copy of sqlite3 to avoid new compiler errors with llvm18. Security: https://vuxml.freebsd.org/freebsd/b058380e-21a4-11ef-8a0f-a8a1599412c6.html PR: 279397 www/chromium/Makefile | 5 +++-- www/chromium/distinfo | 14 +++++++------- ...ty_libaom_source_libaom_aom__ports_aarch64__cpudetect.c | 4 ++-- .../patch-third__party_sqlite_src_amalgamation_sqlite3.c | 11 ++++++++++- www/chromium/files/patch-third__party_zlib_cpu__features.c | 4 ++-- www/chromium/files/patch-v8_src_api_api.cc | 4 ++-- www/ungoogled-chromium/Makefile | 2 +- www/ungoogled-chromium/distinfo | 14 +++++++------- ...ty_libaom_source_libaom_aom__ports_aarch64__cpudetect.c | 4 ++-- .../patch-third__party_sqlite_src_amalgamation_sqlite3.c | 11 ++++++++++- .../files/patch-third__party_zlib_cpu__features.c | 4 ++-- www/ungoogled-chromium/files/patch-v8_src_api_api.cc | 4 ++-- 12 files changed, 50 insertions(+), 31 deletions(-)
I've committed a similar fix, but only for FreeBSD for now as we need to investigate further for other platforms.
(In reply to Robert Nagy from comment #15) > I cannot reproduce this on 13.3/amd64 so I assume this happens due to some > header poisoning from some dependencies. I suppose you did check that all of your patches are in main now? The trigger has to be somewhere in the changes since 125.0.6422.76, but I didn't see anything obvious in port commits. Maybe a chromium upstream change? BTW, we have patches in www/chromium specific to OpenBSD, are we sharing patches with OpenBSD chromium maintainers? Does their port build? > If that is to be upstreamed the comment needs to be fixed up as well. Yeah, it's not meant to be upstreamed just like that, but I'd want to discuss and test the (supposedly) proper fix here before proposing it upstream. Regarding upstream, SQLite still has no pull requests anyway, but they got a support forum since my last SQLite bug fix long time ago. There I found a similar PR: https://www.sqlite.org/forum/forumpost/6a755ae973123d61c7a22aeabbd16d1f2b5747e94fddd59207e56fa9d0b97e66 I think we could offer both the proper fix and one checking for __FreeBSD__ only. They may be hesitant to possibly break other build systems. Long standing bugs tend to become standard ;-)
Having just now recovered from the trauma--whoops, I mean exercise--of fixing for CVE-2024-5274 (with the ad-hoc patch, which worked fine), I'll install the new chromium on my vast local network (has four machines) before I try dealing with the upstreamable fix. But my sincere thanks to all who help maintain chromium on FreeBSD! (One thousand two hundred and ninety-two patch files?? Bravo!)
(In reply to Florian Walpen from comment #19) It is a compiler / freebsd-base change that triggered it, not a chromium change. Yes the patches are shared between OpenBSD and FreeBSD as I maintain the port for both of them.
It seems to me that any way to fix it with a patch so that it can be built is good. However, I think there is something strange about the fact that _XOPEN_SOURCE was defined because there are functions that cannot be used. If it is defined, wouldn't we have to give up on using alloca in the entire source? Isn't it strange that the definition is variable depending on the type of OS? It's not something to do here, though, which is already closed :)
(In reply to commit-hook from comment #17) Following the commit in comment #17, I have successfully compiled sqlite3, and I have a compile of chromium in progress which has gotten past the problematic point. So I'm glad this bug has been closed as fixed. Again, thanks to all!