On 2024-08-11 08:55, Diederik de Haas wrote:
On 03 Aug 2024 11:08:58 -0400 Reinhard Tartler <siret...@tauware.de>
wrote:
I noticed this package is listed as low-NMU. As such, I'm taking the
liberty of uploading the following patch as NMU to sid:
...
new file debian/patches/don-t-fail-on-unknown-gcc-warnings.patch
@@ -0,0 +1,20 @@
+From: Reinhard Tartler <siret...@tauware.de>
+Date: Sat, 3 Aug 2024 10:46:50 -0400
+Subject: don't fail on unknown gcc warnings
+
+---
+ cmake/Helper.cmake | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/cmake/Helper.cmake b/cmake/Helper.cmake
+index f9cdcf2..126e93f 100644
+--- a/cmake/Helper.cmake
++++ b/cmake/Helper.cmake
+@@ -39,7 +39,6 @@ else()
+
+ if(NOT WASMEDGE_PLUGIN_WASI_NN_GGML_LLAMA_CUBLAS)
+ list(APPEND WASMEDGE_CFLAGS
+- -Werror
+ -Wno-error=pedantic
+ )
+ if(CMAKE_CXX_COMPILER_ID MATCHES "GNU" AND
CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 13)
new file debian/patches/series
@@ -0,0 +1 @@
+don-t-fail-on-unknown-gcc-warnings.patch
Why do you consider this an appropriate solution?
Upstream explicitly want all warnings to be treated as errors and now
with gcc-14 it generates a new warning.
This sounds like something upstream explicitly wants to know about?
I think this is a reasonable stance to take upstream. I've now filed
https://github.com/WasmEdge/WasmEdge/issues/3640 to document this issue,
in the hope that someone with more expertise can have a look.
For Debian, I do think that this workaround is acceptable, at least for
the purposes of allowing further testing in the "testing" Distribution,
so that we get additional datapoints whether there actually are runtime
issues that stem from unitialized variables that GCC claims to detect.
-rt
