Bug 92183

Summary: linker.cpp:3187:46: error: ‘strtok_r’ was not declared in this scope
Product: Mesa Reporter: Vinson Lee <vlee>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED WONTFIX QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: lemody, marta.lofstedt
Version: gitKeywords: bisected, regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Vinson Lee 2015-09-29 21:22:39 UTC
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>
Comment 1 Tapani Pälli 2015-09-30 04:37:07 UTC
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.
Comment 2 Ilia Mirkin 2015-09-30 04:37:48 UTC
strtok isn't threadsafe
Comment 3 Tapani Pälli 2015-09-30 04:54:27 UTC
(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?
Comment 4 Tapani Pälli 2015-10-01 05:04:41 UTC
fix pushed to master
Comment 5 Vinson Lee 2015-10-01 07:09:48 UTC
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.
Comment 6 Tapani Pälli 2015-10-07 13:47:11 UTC
(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?
Comment 7 Brian Paul 2015-10-07 14:58:17 UTC
(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
Comment 8 Emil Velikov 2015-10-07 15:28:39 UTC
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.
Comment 9 Tapani Pälli 2015-10-08 06:06:03 UTC
(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.
Comment 10 Jose Fonseca 2015-10-08 12:21:24 UTC
(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.
Comment 11 Brian Paul 2015-10-08 13:59:32 UTC
(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.
Comment 12 Timothy Arceri 2018-04-10 05:59:42 UTC
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.