mesa: cb758b892a7e62ff1f6187f2ca9ac543ff70a096 (master 11.1.0-devel) MinGW and MSVC build error Compiling src/glsl/linker.cpp ... src/glsl/linker.cpp: In function ‘bool included_in_packed_varying(ir_variable*, const char*)’: src/glsl/linker.cpp:3187:46: error: ‘strtok_r’ was not declared in this scope char *token = strtok_r(list, ",", &saveptr); ^ commit 4639cea2921669527eb43dcb49724c05afb27e8e Author: Tapani Pälli <tapani.palli@intel.com> Date: Fri Sep 4 11:30:34 2015 +0300 glsl: add packed varyings to program resource list This makes sure that user is still able to query properties about variables that have gotten packed by lower_packed_varyings pass. Fixes following OpenGL ES 3.1 test: ES31-CTS.program_interface_query.separate-programs-vertex v2: fix 'name included in packed list' check (Ilia Mirkin) v3: iterate over instances of name using strtok_r (Ilia Mirkin) Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
it seems strtok_s would be the windows equivalent: https://msdn.microsoft.com/en-us/library/ftsafwz3.aspx I can make a patch that uses strtok_s when on windows or maybe just go for regular strtok() ? I can see there's some usage of regular strtok() in Mesa.
strtok isn't threadsafe
(In reply to Ilia Mirkin from comment #2) > strtok isn't threadsafe right I'll go for strtok_s, I was just wondering if the occurences of strtok should be converted to mesa_strtok which would then be strtok_r/s or is it worth the trouble?
fix pushed to master
mesa: ca2e16d26ec46e604c76ab72d3ec14a7a8643cc8 (master 11.1.0-devel) Build is still failing on older versions on MinGW. This error occurs with mingw-w64 2.0.1-1 on Ubuntu 12.04. Compiling src/glsl/linker.cpp ... src/glsl/linker.cpp: In function ‘bool included_in_packed_varying(ir_variable*, const char*)’: src/glsl/linker.cpp:3241:46: error: ‘strtok_s’ was not declared in this scope Mesa might decide instead to raise the minimum required version of mingw-w64.
(In reply to Vinson Lee from comment #5) > mesa: ca2e16d26ec46e604c76ab72d3ec14a7a8643cc8 (master 11.1.0-devel) > > Build is still failing on older versions on MinGW. This error occurs with > mingw-w64 2.0.1-1 on Ubuntu 12.04. > > Compiling src/glsl/linker.cpp ... > src/glsl/linker.cpp: In function ‘bool > included_in_packed_varying(ir_variable*, const char*)’: > src/glsl/linker.cpp:3241:46: error: ‘strtok_s’ was not declared in this scope > > > Mesa might decide instead to raise the minimum required version of mingw-w64. Where is the minimum required version documented?
(In reply to Tapani Pälli from comment #6) > (In reply to Vinson Lee from comment #5) > > mesa: ca2e16d26ec46e604c76ab72d3ec14a7a8643cc8 (master 11.1.0-devel) > > > > Build is still failing on older versions on MinGW. This error occurs with > > mingw-w64 2.0.1-1 on Ubuntu 12.04. > > > > Compiling src/glsl/linker.cpp ... > > src/glsl/linker.cpp: In function ‘bool > > included_in_packed_varying(ir_variable*, const char*)’: > > src/glsl/linker.cpp:3241:46: error: ‘strtok_s’ was not declared in this scope > > > > > > Mesa might decide instead to raise the minimum required version of mingw-w64. > > Where is the minimum required version documented? Off-hand I don't think the min version is documented. I routinely use MinGW 4.6.3: $ i686-w64-mingw32-g++ --version i686-w64-mingw32-g++ (GCC) 4.6.3
Iirc the mingw + autoconf build was dropped. So we might want to 'sync' with the autoconf build. The latter currently requires gcc 4.2, whist 4.6 is recommended. Although as Brian said, I'm not sure if we have that explicitly documented.
(In reply to Emil Velikov from comment #8) > Iirc the mingw + autoconf build was dropped. So we might want to 'sync' with > the autoconf build. The latter currently requires gcc 4.2, whist 4.6 is > recommended. > > Although as Brian said, I'm not sure if we have that explicitly documented. So do I understand correctly that adding such a requirement to documentation would fix this bug? I would prefer some mingw user to do this so that I won't mess this up.
(In reply to Brian Paul from comment #7) > I routinely use MinGW 4.6.3: > > $ i686-w64-mingw32-g++ --version > i686-w64-mingw32-g++ (GCC) 4.6.3 If this version is still widely used, then it would be nice to keep it building. That said, I'm afraid I can't help. I used 4.6 for a long time (as for a period of time, certain mingw versions introduced a dependency of winpthreads-1.dll) but newer versions (e.g., Ubtuntu 15.04's) no longer depend on it, so I stopped using it. (In reply to Emil Velikov from comment #8) > Iirc the mingw + autoconf build was dropped. So we might want to 'sync' with > the autoconf build. The latter currently requires gcc 4.2, whist 4.6 is > recommended. > > Although as Brian said, I'm not sure if we have that explicitly documented. It's not just the GCC version that matter for mingw. More than that, it's the MinGW runtime headers themselves.
(In reply to Jose Fonseca from comment #10) > (In reply to Brian Paul from comment #7) > > I routinely use MinGW 4.6.3: > > > > $ i686-w64-mingw32-g++ --version > > i686-w64-mingw32-g++ (GCC) 4.6.3 > > If this version is still widely used, then it would be nice to keep it > building. Yeah, I'd rather not have to update my MinGW tool chain right now. > That said, I'm afraid I can't help. > > I used 4.6 for a long time (as for a period of time, certain mingw versions > introduced a dependency of winpthreads-1.dll) but newer versions (e.g., > Ubtuntu 15.04's) no longer depend on it, so I stopped using it. That's certainly good news. The winpthreads-1.dll dependency was a huge PITA.
It's be 3 years I think its safe to say the solution is: Use a newer version of MinGW :)
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.