Summary: | x11-drivers/nvidia-drivers-545.29.06: error: initialization of ‘int (*)(struct drm_gem_object *, struct iosys_map *)’ from incompatible pointer type ‘void * (*)(struct drm_gem_object *)’ [-Wincompatible-pointer-types] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Fore <csfore> |
Component: | Current packages | Assignee: | Ionen Wolkens <ionen> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | soap |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://forums.developer.nvidia.com/t/nvidia-modules-build-failure-with-upcoming-gcc-14-and-recent-kernels-due-to-misfiring-conftest-sh-test-heads-up/279072 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 870412 | ||
Attachments: | build.log |
Description
Christopher Fore
2024-01-05 03:41:17 UTC
Wonder why nv_drm_gem_prime_vmap and nv_drm_gem_vmap are implemented differently. Perhaps differences between kernels? gem_prime_vmap returns a void pointer, gem_vmap an int, and well... .vmap = nv_drm_gem_prime_vmap certainly does not expect a function that returns a void pointer but rather an int (vunmap is less of a problem). My best guess would be that this code doesn't need fixing and that the NV_DRM_GEM_OBJECT_VMAP_HAS_MAP_ARG test is misfiring (which stops it from using nv_drm_gem_vmap over prime). Also thanks for the fine /dev/null on every tests. $CC $CFLAGS -c conftest$$.c > /dev/null 2>&1 conftest4394.c: In function 'conftest_drm_gem_object_vmap_has_map_arg': conftest4394.c:24:46: error: passing argument 2 of 'obj->funcs->vmap' from incompatible pointer type [-Wincompatible-pointer-types] 24 | return obj->funcs->vmap(obj, map); | ^~~ | | | struct dma_buf_map * conftest4394.c:24:46: note: expected 'struct iosys_map *' but argument is of type 'struct dma_buf_map *' Ok, guess it all makes sense now. /* * The 'dma_buf_map' structure is renamed to 'iosys_map' by the commit * 7938f4218168 ("dma-buf-map: Rename to iosys-map"). */ #if defined(NV_LINUX_IOSYS_MAP_H_PRESENT) typedef struct iosys_map nv_sysio_map_t; #else typedef struct dma_buf_map nv_sysio_map_t; #endif The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9b89609eb1e84c5f5077039c7ff1d7865a81f85f commit 9b89609eb1e84c5f5077039c7ff1d7865a81f85f Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-01-15 22:28:24 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-01-15 23:00:44 +0000 x11-drivers/nvidia-drivers: fix build with upcoming gcc14 Trivial and proper fix for 5xx branches, NVIDIA seems to be (now) keeping track of implicits and incompatibles beside missing this one hidden behind 2>/dev/null and kernel >=5.18. Can't say the same for the legacy branches (390 and 470), and rather than worry about these going for the lame life support treatment with -Wno-error= there. 470 has hope to be fixed properly by NVIDIA still but this is likely there forever in the not supported + masked 390. No need for revbumps, with gcc13 the test simply functions properly and does what's right, while with 14 it's just a build-time issue (and legacy branches are unchanged). Closes: https://bugs.gentoo.org/921370 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../files/nvidia-drivers-525.147.05-gcc14.patch | 32 ++++++++++++++++++++++ .../nvidia-drivers/nvidia-drivers-390.157.ebuild | 11 ++++++++ .../nvidia-drivers-470.223.02.ebuild | 13 +++++++++ .../nvidia-drivers-525.147.05.ebuild | 1 + .../nvidia-drivers-535.146.02.ebuild | 1 + .../nvidia-drivers/nvidia-drivers-535.43.22.ebuild | 1 + .../nvidia-drivers-545.29.06-r1.ebuild | 1 + 7 files changed, 60 insertions(+) |