Closed namaenonaimumei closed 3 years ago
Is it fixed with the patch you sent (and that has been merged)?
I wasn't sure whether it was worked on, since last commit around it looked unfinished.
If you would be fine with it I could refactor FT_Error_String()
to actually wrap around freetype's own implementation instead, since current version doesn't do anything.
Just noticed, that by mistake I submitted changed FTGL_Error_String()
in already merged PR, so it no longer clashes with freetype_s in current master.
This has been fixed with pr above. Forgot to close the issue.
Issue happens when linking together freetype-gl and freetype_s libraries.
Probably regression introduced in cf8c572, since commits before that work fine. Currently changing internal name to something like
FTGL_Error_String()
works, but not really sure what is being achieved in that code scope, since to me it makes no sense other than placeholder (always returns ERROR_UNKNOWN). Since I wasn't sure about reason for current state ofFT_Error_String()
, not creating pr for this one - for now renaming function works as workaround. Not sure why not to useFT_Error_String()
provided by freetype directly.Error itself probably didn't happen when dynamically loading library, but only tested with slib.
Error with MSVC under Windows with vc142.