Sync from SUSE:SLFO:Main graphviz revision cb2d4bc79a3c97626ccaef86fd7a5fc1

This commit is contained in:
Adrian Schröter 2024-10-03 18:15:36 +02:00
parent 04e1a86bd4
commit ada596dd94
4 changed files with 109 additions and 2 deletions

View File

@ -0,0 +1,18 @@
Silent warning:
>> tbl.c:173:15: warning: assignment to char * from incompatible pointer type char (*)[1] [-Wincompatible-pointer-types]
---
cmd/lefty/tbl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- cmd/lefty/tbl.c
+++ cmd/lefty/tbl.c 2024-09-06 08:48:48.059367033 +0000
@@ -170,7 +170,7 @@ Tobj Tcode (Code_t *cp, int ci, int cl)
cp2[i] = cp[i];
if (cp2[i].next != C_NULL)
cp2[i].next -= ci;
- s = &cp[i].u.s;
+ s = &cp[i].u.s[0]; // gcc14
while (*s)
s++;
cn = (long) (s - (char *) &cp[i]) / sizeof (Code_t);

67
graphviz-87cc546.patch Normal file
View File

@ -0,0 +1,67 @@
From 87cc54644e40fccc0651b7fedc137b3dd02b4514 Mon Sep 17 00:00:00 2001
From: Matthew Fernandez <matthew.fernandez@gmail.com>
Date: Mon, 21 Mar 2022 08:09:55 -0700
Subject: [PATCH] smyrna Init: squash -Wincompatible-pointer-types
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
OpenGL has an unorthodox API wherein the `gluTessCallback` functions prototype
indicates it takes a `void(*)(void)`, but its docs¹ explain that the type
actually varies depending on the second argument. As a result, the compiler
(correctly) warns that some of these `gluTessCallback` calls are passing
function pointers that do not have the same ABI. Presumably this works out
because at the end of the day a function pointer is just some bits in C and the
OpenGL implementation branches on the `which` argument and invokes the pointer
correctly. But if OpenGL really wanted to discard type safety this way, it is
not clear to me why they did not make the function pointer argument a `void*`.
Anyway, this commit squashes the compiler warnings which emerge when enabling
this in the CMake build system, failing the build.
Gitlab: related to #1836
¹ This is not the authoritative source, but Microsofts docs for their
implementation provide a good explanation.
https://docs.microsoft.com/en-us/windows/win32/opengl/glutess
---
cmd/smyrna/polytess.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
--- cmd/smyrna/polytess.c
+++ cmd/smyrna/polytess.c 2024-09-06 09:04:16.790734526 +0000
@@ -39,15 +39,30 @@ static void CALLBACK vertexCallback(GLvo
}
-static GLUtesselator* Init()
+// OpenGLs `gluTessCallback` function has a prototype indicating it takes a
+// `void(*)(void)`. But its documentation describes passing in various function
+// pointers with differing calling conventions. To use this API while also
+// pacifying all the various build environments, we need this rather silly
+// wrapper.
+#ifdef _MSC_VER
+// MSVC is of the (correct) opinion that casting between function pointers of
+// incompatible calling conventions is unacceptable behavior…
+#define MAKE_GLU_CALLBACK(f) f
+#else
+// …nevertheless other compilers insist we cast or they believe we have made a
+// typo
+#define MAKE_GLU_CALLBACK(f) ((void (*)(void))(f))
+#endif
+
+static GLUtesselator* Init(void)
{
// Create a new tessellation object
GLUtesselator* tobj = gluNewTess();
// Set callback functions
- gluTessCallback(tobj, GLU_TESS_VERTEX, &vertexCallback);
- gluTessCallback(tobj, GLU_TESS_BEGIN, &glBegin);
- gluTessCallback(tobj, GLU_TESS_END, &glEnd);
- gluTessCallback(tobj, GLU_TESS_COMBINE,&combineCallback);
+ gluTessCallback(tobj, GLU_TESS_VERTEX, MAKE_GLU_CALLBACK(vertexCallback));
+ gluTessCallback(tobj, GLU_TESS_BEGIN, MAKE_GLU_CALLBACK(glBegin));
+ gluTessCallback(tobj, GLU_TESS_END, MAKE_GLU_CALLBACK(glEnd));
+ gluTessCallback(tobj, GLU_TESS_COMBINE, MAKE_GLU_CALLBACK(combineCallback));
return tobj;
}

View File

@ -1,3 +1,19 @@
-------------------------------------------------------------------
Fri Sep 6 09:08:28 UTC 2024 - Dr. Werner Fink <werner@suse.de>
- For bug boo#1225776 add patches
* graphviz-2.49.3-boo1225776-gcc14.patch silent warning/error
on incompatible pointer type
* graphviz-87cc546.patch
also fix incompatible pointer type
-------------------------------------------------------------------
Tue Jul 9 13:46:12 UTC 2024 - Martin Jambor <mjambor@suse.com>
- Add -fpermissive to optflags when compiling the addons flavor in
order to prevent GCC 14 to throw errors upon encountering various
C99 violations. [boo#1225776]
-------------------------------------------------------------------
Thu Mar 7 14:57:35 UTC 2024 - Thomas Renninger <trenn@suse.de>

View File

@ -1,5 +1,5 @@
#
# spec file for package graphviz
# spec file
#
# Copyright (c) 2024 SUSE LLC
#
@ -78,6 +78,10 @@ Patch6: graphviz-no_php_extra_libs.patch
Patch7: swig-4.1.0.patch
#PATCH-FIX-UPSTREAM gvc: detect plugin installation failure and display an error
Patch8: gvc-detect-plugin-installation-failure-and-display-an-error.patch
#PATCH-FIX-OPENSUSE Bug 1225776 - Flavor addons of package graphviz does not build with gcc14
Patch9: graphviz-2.49.3-boo1225776-gcc14.patch
#PATCH-FIX-UPSTREAM
Patch10: graphviz-87cc546.patch
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: bison
@ -409,6 +413,8 @@ programs that use the graphviz libraries including man3 pages.
%patch -P 6
%patch -P 7 -p1
%patch -P 8 -p1
%patch -P 9
%patch -P 10
# pkg-config returns 0 (TRUE) when guile-2.2 is present
if pkg-config --atleast-version=2.2 guile-2.2; then
@ -430,7 +436,7 @@ CFLAGS="%{optflags} -ffast-math -fno-strict-aliasing -fno-strict-overflow -fPIC"
%if "%{flavor}" == "addons"
CFLAGS="$CFLAGS -I/usr/include/ruby-%{ruby_version}.0"
CFLAGS="$CFLAGS -I/usr/include/ruby-%{ruby_version}.0 -fpermissive"
#seems to be broken? gives -I/usr/lib64/ruby/2.6.0/x86_64-linux-gnu, ruby.h is in /usr/lib64/ruby/2.6.0
#CFLAGS="$CFLAGS $(pkg-config --cflags ruby-$(echo {rb_ver} | sed 's|\.[^.]*$||'))"