We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5139

Summary: SDL_TTF windows MinGW build is broken in latest hg
Product: SDL_ttf Reporter: Ellie <etc0de>
Component: miscAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: blocker    
Priority: P2 CC: sylvain.becker
Version: unspecified   
Hardware: x86_64   
OS: Linux   
Attachments: Maybe this helps...? But I don't have MSVC, so I really don't know for sure what I am even fixing

Description Ellie 2020-05-15 11:29:42 UTC
The SDL_TTF in latest hg no longer compiles for Windows when using anything but MSVC. The reason is this header guard:

#ifdef _WIN32
typedef TTF_Font::PosBuf PosBuf_t;
#else
typedef void PosBuf_t;
#endif


It should be instead something like #if defined(MSVC), or some other way to actually detect a C/C++ mixed compiler.

This is the error I am seeing:

bin/bash ./libtool  --tag=CC   --mode=compile x86_64-w64-mingw32-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"SDL2_ttf\" -DVERSION=\"2.0.15\" -I.     -g -O2 -I"/compile-tree/vendor/freetype2/include/" -I/usr/include/SDL2 -D_REENTRANT -MT SDL_ttf.lo -MD -MP -MF .deps/SDL_ttf.Tpo -c -o SDL_ttf.lo SDL_ttf.c
libtool: compile:  x86_64-w64-mingw32-gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"SDL2_ttf\" -DVERSION=\"2.0.15\" -I. -g -O2 -I/compile-tree/vendor/freetype2/include/ -I/usr/include/SDL2 -D_REENTRANT -MT SDL_ttf.lo -MD -MP -MF .deps/SDL_ttf.Tpo -c SDL_ttf.c -o SDL_ttf.o
SDL_ttf.c:248:17: error: expected identifier or '(' before ':' token
 typedef TTF_Font::PosBuf PosBuf_t;
                 ^

I did sent a small direct e-mail about this shortly after that commit went in, so apologies if this is already being worked on.
Comment 1 Sylvain 2020-05-15 15:24:35 UTC
There was two commits, can you check them:

https://hg.libsdl.org/SDL_ttf/rev/b7b5a1959877
https://hg.libsdl.org/SDL_ttf/rev/2ae899daf9e3

Do you have a tested patch to solve it ?
Comment 2 Ellie 2020-05-15 15:54:40 UTC
Thinking more about it, I don't even understand where this namespace TTF_Font:: is suddenly coming from. Is that something SDL_TTF internally does when it detects MSVC to somehow namespace things better? Is that a freetype thing? Why is freetype adding in C++ namespaces all of a sudden when used from a C library like SDL_TTF in MSVC? This all seems a bit fishy to me, I don't really understand what is going on.

So I feel like I don't have enough information to be sure what would be a good fix, beyond just somehow getting it to work for myself, which is a bit unsatisfying.
Comment 3 Sylvain 2020-05-15 17:48:48 UTC
This is the internal/private SDL_ttf C data structure,
Sam use it as a cast in https://hg.libsdl.org/SDL_ttf/rev/2ae899daf9e3
"Fixed building with Visual Studio 2017"
indeed this is, C not Cpp.

I don't have all the Visual Studio right now, but I think I tried it with visual 2017 before.

I never tried mingw, so please provide a tested patch for the working behaviour on this platform.
Comment 4 Ellie 2020-05-15 18:26:41 UTC
I have been writing C for a while, and I have never seen :: in a C program in my life.

My wild guess is the actual problem is that the code wants to use PosBuf_t to refer to PosBuf, but it's an internal struct so it hacks around it with void*, and now the code uses some MSVC-specific non-standard extension to shut up a legitimate warning that maybe it should refer to the proper struct posbuf instead.

I think the actual fix might be to move out struct posbuf's definition and stop trying to hide a struct that is only file local anyway, and then not use any compiler-specific extensions.

I could be wrong though, since I really don't understand what this :: is. But I'm pretty sure it's not standard C
Comment 5 Ellie 2020-05-15 18:29:36 UTC
Disclaimer: I don't have MSVC, therefore this might all be wrong. I haven't even seen the warning, and I don't think it makes sense to touch this code before getting to the bottom why this weird syntax is used. (Or if it's indeed valid C, then I shouldn't touch it for sure because I have never seen this, so I am not qualified for this particular corner case.)
Comment 6 Ellie 2020-05-15 18:45:28 UTC
Created attachment 4342 [details]
Maybe this helps...? But I don't have MSVC, so I really don't know for sure what I am even fixing
Comment 7 Sylvain 2020-05-15 18:52:47 UTC
I did almost the same patch https://hg.libsdl.org/SDL_ttf/rev/f7cbb6d633e9
Thanks ! Please double check!
Comment 8 Ellie 2020-05-16 12:37:57 UTC
I just checked things, and it works fine! Thanks so much for the fix!