On Sat, Mar 11, 2023 at 08:24:58AM +0000, Ali Farzanrad wrote:
> Thomas Frohwein <tfrohwein@fastmail.com> wrote:
> > On Fri, Mar 10, 2023 at 08:36:06PM +0000, Ali Farzanrad wrote:
> > [...]
> > > > > Please leave in the hunk that removes -Werror
> > > >
> > > > yes, what's the reason for this being in the diff/
> > >
> > > I thought that you've removed that -Werror mistakenly, because it was
> > > used to detect compiler options and without that flag it's functionality
> > > (compiler flags detection) is broken.
tradcpp(1):
-Werror Make warnings into fatal errors.
There is a reason why this was removed. It wasn't mentioned in this
particular port when the patch to remove -Werror was committed, but
we have had ports abort for innocuous warnings.
> >
> > I see those. I feel like there must be a better way to silence those
> > unused flags. Here they are:
> >
> > cc: warning: optimization flag '-fweb' is not supported [-Wignored-optimization-argument]
> > cc: warning: optimization flag '-frename-registers' is not supported [-Wignored-optimization-argument]
>
> OK, but I think it is better to remove the compiler option detection
> functionality compeletely, instead of breaking it, right?
Maybe I misunderstood you, but it sounded to me like your goal with
patching in -Werror or patching out check_gcc was to make the above
warnings go away.
If you look through the Makefile, you will find these options aren't added
by the compiler option detection, but inside the Makefile:
$ ag -s "(fweb|frename.registers)" Quake/Makefile
62:CFLAGS += $(call check_gcc,-fweb,)
63:CFLAGS += $(call check_gcc,-frename-registers,)
The actual question is if there is any value in keeping these options
(and the warnings) active or not. Given that GCC supports them, I think
the easiest way is to leave them in, whether or not clang will support
them, because we still have ports-gcc arches.
[...]
> -check_gcc = $(shell if echo | $(CC) $(1) -Werror -S -o /dev/null -xc - > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi;)
[...]
> CFLAGS += $(CPUFLAGS)
> +CFLAGS += -DUSE_CRT_MALLOC
> ifneq ($(DEBUG),0)
> DFLAGS += -D_DEBUG
> CFLAGS += -g
> do_strip=
> else
> DFLAGS += -DNDEBUG
> -CFLAGS += -O3
> -CFLAGS += $(call check_gcc,-fweb,)
> -CFLAGS += $(call check_gcc,-frename-registers,)
> -CFLAGS += $(call check_gcc,-fno-asynchronous-unwind-tables,)
> -CFLAGS += $(call check_gcc,-fno-ident,)
> +CFLAGS += -fweb
> +CFLAGS += -frename-registers
This doesn't make any sense, you are still adding -fweb and
-frename-registers.
If there is harm in using check_gcc, please explain more clearly.
[...]
> > > Server using protocol 999+ (FTE-RMQ)
> > > Exe: 21:30:40 Mar 10 2023
> > >
> > > Vulkan Initialization
> > > Using Vulkan 1.1
> > > Instance extensions:
> > > VK_KHR_surface
> > > VK_KHR_xlib_surface
> > > VK_KHR_get_surface_capabilities2
> > > VK_KHR_get_physical_device_properties2
> > >
> > >
> > > ERROR-OUT BEGIN
> > >
> > >
> > > QUAKE ERROR: Couldn't find any Vulkan devices
> > >
[...]
> >
> > I don't get an error like yours. Do vulkaninfo and vkcube work?
>
> No, they don't work too:
> $ vulkaninfo
> ERROR: [Loader Message] Code 0 : remove_all_non_valid_override_layers: Failed to get executable path and name
> ERROR: [Loader Message] Code 0 : setup_loader_term_phys_devs: Failed to detect any valid GPUs in the current config
> ERROR at /usr/obj/ports/vulkan-tools-1.3.239.0/Vulkan-Tools-sdk-1.3.239.0/vulkaninfo/vulkaninfo.h:237:vkEnumeratePhysicalDevices failed with ERROR_INITIALIZATION_FAILED
> $ vkcube
> vkEnumeratePhysicalDevices reported zero accessible devices.
>
> Do you have a compatible Vulkan installable client driver (ICD) installed?
> Please look at the Getting Started guide for additional information.
Looks like your problem is with not having a vulkan-compatible video
device. If you want to find out why, look at your GPU (maybe share a
dmesg), and inspect glxinfo -B.
vkquake is closely derived from quakespasm. Maybe try quakespasm if
your opengl acceleration works and you want to play quake.
No comments:
Post a Comment