On 03/05/2016 02:01 PM, Jose Fonseca wrote:
On 05/03/16 17:40, Brian Paul wrote:Fixes VMware MSVC, MinGW builds: build/windows-x86-debug/mesa/libmesa.a(ir_to_mesa.o): ir_to_mesa.cpp:(.rdata+0xf9c): undefined reference to `program_resource_visitor::set_buffer_offset(unsigned int)' This doesn't seem to be needed for the libgl-gdi target, however. --- src/mesa/program/ir_to_mesa.cpp | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mesa/program/ir_to_mesa.cpp index 10d931c..d9338e0 100644 --- a/src/mesa/program/ir_to_mesa.cpp +++ b/src/mesa/program/ir_to_mesa.cpp @@ -2318,6 +2318,10 @@ public: } private: + virtual void set_buffer_offset(unsigned offset) + { + } + virtual void visit_field(const glsl_type *type, const char *name, bool row_major);program_resource_visitor::set_buffer_offset is not pure virtual. There shouldn't be a need to implement it on derived classes. The program_resource_visitor::set_buffer_offset implementation from src/compiler/glsl/link_uniforms.cpp should normally be picked up. So, somehow link_uniforms.cpp 's symbol is being picked up when building libgl-gdi target, but not when building the failing targets. Usually I'd say link order is the cause of this sort of issues. But the odd thing is that MSVC is failing too, and unlike GCC's, MSVC's linker usually is not sensitive to build order. So the problem might be more subtle... Still it's probably worth checking if tweaking the build order helps in anyway.
The problem was our non-clean build was picking up a stale copy of libglsl.a from before the glsl/ -> compiler/glsl/ move. Thanks for finding that, Jose.
This patch is not needed. -Brian _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
