Summary: | build fails on nouveau_stateobj.h | ||
---|---|---|---|
Product: | Mesa | Reporter: | Kevin Hobbs <hobbsk> |
Component: | Other | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Kevin Hobbs
2010-05-28 10:21:11 UTC
The Fedora 12 x86_64 workstation is missing the Nouveau header files. They can be obtained from the libdrm package. This workstation does have rpm -q libdrm libdrm-devel libdrm-2.4.18-2.fc12.x86_64 libdrm-2.4.18-2.fc12.i686 libdrm-devel-2.4.18-2.fc12.x86_64 I took a look at /usr/include/nouveau/nouveau_channel.h where nouveau_channel is defined and there is nothing there called "cur". The rest of the code around the line that is producing the error refers to so->cur instead of chan->cur could this be a typo? As I understand it this build target should not depend on any hardware but should build software Mesa and OSMesa. Can you try a newer version of the Nouveau headers from libdrm-2.4.18 proper or later? The top-of-tree nouveau/nouveau_channel.h has struct nouveau_channel member cur. drm: 607e228c263d5d171bd0615d5d93202dda371e5f (master) nouveau/nouveau_channel.h 31 struct nouveau_channel { 32 uint32_t *cur; 33 uint32_t *end; 34 35 struct nouveau_device *device; 36 int id; 37 38 struct nouveau_grobj *nullobj; 39 struct nouveau_grobj *vram; 40 struct nouveau_grobj *gart; 41 42 void *user_private; 43 void (*hang_notify)(struct nouveau_channel *); 44 void (*flush_notify)(struct nouveau_channel *); 45 46 struct nouveau_subchannel subc[8]; 47 unsigned subc_sequence; 48 }; (In reply to comment #3) > Can you try a newer version of the Nouveau headers from libdrm-2.4.18 proper or > later? > Ahhhh I see the libdrm that comes with Fedora 12 is patched to revert this change. From the .spec : # revert nouveau to interface available in F12 kernel Patch5: nouveau-revert-to-0.0.15.patch I do not think updateing libdrm will help me test what I want to test which is the future Mesa software renderer. I think the only issue left for this bug is that the linux-x86-64 target shouldn't be building this driver anyway. That's for the linux-dri targets. As a workaround try removing 'nvfx' and 'nv50' from GALLIUM_DRIVERS_DIRS in configs/default:112. configs/default 108 # Gallium directories and 109 GALLIUM_DIRS = auxiliary drivers state_trackers 110 GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a 111 GALLIUM_DRIVERS_DIRS = softpipe trace rbug identity i915 i965 svga r300 nvfx nv50 failover 112 GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a) 113 GALLIUM_WINSYS_DIRS = sw sw/xlib 114 GALLIUM_TARGET_DIRS = libgl-xlib 115 GALLIUM_STATE_TRACKERS_DIRS = glx vega (In reply to comment #5) > As a workaround try removing 'nvfx' and 'nv50' from GALLIUM_DRIVERS_DIRS in > configs/default:112. > Removing these directories does allow the build to proceed. Marking as fixed. Reopen if it's still a problem. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.