search

vvollaro / freetype-gl

Automatically exported from code.google.com/p/freetype-gl
Other
0 stars 0 forks source link

Visual C++ 10 Compilation errors #45

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hello,

Recently I wanted to compile freetype-gl library with Visual C++ 10 (from
project files created using CMake), and I came across several issues.

Forget for a while about demos.
I changed the project to build as C++ (issue 34), but it was not enough.

File texture-font.c lacks #include "platform.h" (in both trunk and
branch 3.0), which defines round function.

In branch 3.0 there are errors about undeclared indentifier M_PI in
mat4.h - so I have added:
#ifndef M_PI
#    define M_PI 3.14159265358979323846
#endif
in file mat4.c

Another issue was related to include paths and linking against required
libraries. I am not accustomed to CMake, but maybe a variable for
specifying location of them is something that can be considered?
Nevertheless, to make everything as simple as possible, and without
modifying project's include paths, I simply copied required libraries
into main folder (svn/trunk and svn/branches/gl-3.0, respectively).

In 3.0 branch an issue arised about undefined identifier strndup in
vertex-attribute.c, so I have added the following (it is defined in another c 
file - let external linkage do the job):

#if defined(__APPLE__) || defined(_WIN32) || defined(_WIN64)
char *
strndup( const char *s1, size_t n);
#endif

Now proceeding with both branches splits.
For gl-3.0, I compiled against the latest glew, i.e. 1.9.0.
For trunk, I have compiled against some legacy glew version I have
found somewhere on my computer, because there was a name conflict with
respect to GL_TYPE in file vertex-attribute.c.

Now both static libraries compiled fine (there were a lot of warnings
about possible loss of data in text-buffer.c, mat4.c and others, and
about unsafe functions - I did not focus on solving them).

Since libraries were working, I focused on compiling demos. I have
chosen demo-subpixel, because I was especially interested in it.
This demo project I changed to build as C++ as well. After fixing
markup definition (strange syntax, huh), I received a lot of linker
errors (LNK2019) complaining about various unresolved glew external
symbols in both trunk and branch-3.0. All of them disappeared after
adding glew32.lib to additional dependencies (shouldn't this be done
automatically?).
BTW, there is a nice mess with locations of various libraries; e.g.:
additional dependency is hardcoded:
 - freetype-gl/freetype-gl/svn/branches/gl-3.0/windows/freetype/freetype.lib
yet additional include directory for ft2build.h is not;
 - static libraries files (glew32.lib, glut32.lib) are expected in
main folder, yet glew.h is expected in GL folder which does not exist;
 - glut.h is expected in GLUT folder which does not exist in main
directory, but only in windows one;
 - additional library directory
freetype-gl/freetype-gl/svn/branches/gl-3.0/$(Configuration) 
is specified for no reason;
 - folder Fonts is not being copied into build location for gl-3.0;
 - folders Fonts and Shaders should be copied into $(Configuration)
rather than main build directory.

It is not hard to make the solution running, but one would expect
CMake to deal with it, I guess.

I also decided to check SDF examples, and the file "edtaa3func.c"
lacks #include "edtaa3func.h". Without it in C++ it results in LNK2019. 
From my C++ experience it makes perfect sense why this is
needed, but since I haven't written even one plain C program, I can't
tell you why in C this is not required :)
In other demos I have experienced other various issues, but I think it
is enough complains for now :)

On gl-3.0 all examples worked nicely (I have checked just few of them
- most of them require some additional functions I did not want to
seek for over the internet).
The problem arises with trunk's demo-subpixel which crashes somewhere
in between vertex_buffer_new and vertex_attribute_new. Debugger shows
line no. 180 in vertex-attribute.c as the next statement to be
executed.

Hope that helps.
PS. demo-cartoon does crash exactly in the same place.

One final question: I have compiled (gl-3.0) and run demo-subpixel
(compiled against FT with LCD rendering enabled), yet the resultant
text is only antialiased. Any ideas as to why?

regards

Original issue reported on code.google.com by wmam...@gmail.com on 28 Jan 2013 at 9:03

GoogleCodeExporter commented 9 years ago 

Hi Wojcieh,

Thanks a lot for he code review. I tried to modify sources according to your 
comment (only gl-3.0 since it will be the main branch soon) but the part  on 
the various path remains quite a mystery to me because I do not masterize CMake 
at all. Did you manage to fix the Cmakefile by any chance ?

Concerning the subpixel demo, it depends mainly if you compiled freetype with 
subpixel support or not. You have to check for 
FT_CONFIG_OPTION_SUBPIXEL_RENDERING in freetype2/freetype/ftconfig/ftoption.h 

Nicolas

Original comment by Nicolas.Rougier@gmail.com on 4 Feb 2013 at 1:56

GoogleCodeExporter commented 9 years ago 
I can try to fix CMake errors.

I compiled latest freetype version (2.4.11) with subpixel support on. In my own 
projects subpixel does work nicely.

Original comment by wmam...@gmail.com on 4 Feb 2013 at 2:14

GoogleCodeExporter commented 9 years ago 
That would be great !

Original comment by Nicolas.Rougier@gmail.com on 4 Feb 2013 at 2:19

GoogleCodeExporter commented 9 years ago 
I applied a patch for fixing C89 / visual C++. Hopefully it will fix these 
problems as well.
It's in the gl-3.0 branch.

Original comment by Nicolas.Rougier@gmail.com on 20 Feb 2013 at 10:54

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Sorry for the long delay.
I haven't encountered any CMake errors with current trunk version. Good job.
In case something is unclear in the following message, write.

There are few compilation/linking errors (Visual C++ 10):
[1]
freetype-gl\platform.c(42): error C2371: 'round' : redefinition; different 
basic types
freetype-gl\platform.h(61) : see declaration of 'round'

solution: change return type to double.

[2]
in file freetype-gl\demo-cube.c change #include <GL/glut.h> to #include <glut.h>

[3]
there are (literally) thousands of warnings: 
warning C4309 : 'initializing' : truncation of constant value 
and 
warning C4305: 'initializing' : truncation from 'double' to 'float'

in freetype-gl\arial-16.h

The latter can be solved by adding constant literal f at the end of each 
floating point number (not manually, in generator) or changing type to double, 
and the former by changing char tex_data[16384]; to unsigned char 
tex_data[16384]; in freetype-gl\arial-16.h(61).

[4]
There is a linkage error:
error LNK2005: _font already defined in demo-makefont.obj

This is caused by tentative definitions being absent in C++. It can be solved 
by moving initialization of `texture_font_t font` into (new) arial-16.c file 
and adding extern in front of this declaration.

Except that, I am getting quite significant number of other warnings (mostly 
related to conversions and warning LNK4098: defaultlib 'LIBCMT' conflicts with 
use of other libs; use /NODEFAULTLIB:library), but let me focus on them later 
on :)

regards

Original comment by wmam...@gmail.com on 2 Apr 2013 at 11:33

GoogleCodeExporter commented 9 years ago 
LIBCMT warning disappered when I linked against correct freetype lib.

Original comment by wmam...@gmail.com on 2 Apr 2013 at 12:00

GoogleCodeExporter commented 9 years ago 
I'm reopening this issue since I did not fix [4]. Do you mean it's necessary to 
split the output (arial-16.h) into two separate files, arial-16.c starting at 
texture_font_t font = { 128, 128, 1, ... ?

Original comment by Nicolas.Rougier@gmail.com on 9 Apr 2013 at 5:41

GoogleCodeExporter commented 9 years ago 
no, wait, leave it as is, I need to investigate it more deeply. It is something 
much more strange.

Original comment by wmam...@gmail.com on 9 Apr 2013 at 8:52

GoogleCodeExporter commented 9 years ago 
Got it, file `arial-16.h` has incorrect `Item type` - `C/C++ compiler` instead 
of `C/C++ header`.
BTW, is there any reason to wrap entire arial-16 withextern C?

Original comment by wmam...@gmail.com on 9 Apr 2013 at 9:48

GoogleCodeExporter commented 9 years ago 
I do not remember the reason indeed.

Should I close the issue ?

Original comment by Nicolas.Rougier@gmail.com on 2 May 2013 at 9:55

GoogleCodeExporter commented 9 years ago 
If item types is fixed, then yes :)

Original comment by wmam...@gmail.com on 2 May 2013 at 10:53

GoogleCodeExporter commented 9 years ago 
Hi There.It is already my second attempt to compile your lib with VS2010.I am 
getting all sort of errors in demo-font.c Like symtax error which are not 
really exist.I set the compiler to be C instead of CPP and still the same.Is 
this project compatible with VS and C++ compilers? If yes ,can you briefly 
explain how do get it work?Thanks a lot.

Original comment by explomas...@gmail.com on 2 May 2013 at 3:54

GoogleCodeExporter commented 9 years ago 
In fact I almost got it compiled.In demo-ansi.c this block :

 markup_t markup = {
        .family  = "fonts/VeraMono.ttf",
        .size    = 15.0, .bold    = 0,   .italic  = 0,
        .rise    = 0.0,  .spacing = 0.0, .gamma   = 1.0,
        .foreground_color    = black, .background_color    = none,
        .underline           = 0,     .underline_color     = black,
        .overline            = 0,     .overline_color      = black,
        .strikethrough       = 0,     .strikethrough_color = black,
        .font = 0,
    };

Throws syntax error.If I comment it out the project compiles.How can I adjust 
this block for VS2010?

Original comment by explomas...@gmail.com on 2 May 2013 at 4:17

GoogleCodeExporter commented 9 years ago 
@Nicolas:
change line #133 in CMakeLists.txt to DEMO( demo-make             
"demo-makefont.c" )

@14: update to the latest revision.

Original comment by wmam...@gmail.com on 3 May 2013 at 3:11

GoogleCodeExporter commented 9 years ago 
Hey!! Thanks for help.Now it compiles and runs.But it exist here: 

    fprintf( stderr, "\"font_manager_get_from_description\" not implemented yet.\n" );
Does it mean this example works on Linux only? 

Thanks!

Original comment by explomas...@gmail.com on 5 May 2013 at 1:47

GoogleCodeExporter commented 9 years ago 
Unfortunately, yes. I do not know how to query a specific font from its 
description under windows.
You can however run the related demo by giving explicitly the font filename.

Original comment by Nicolas.Rougier@gmail.com on 5 May 2013 at 1:55

GoogleCodeExporter commented 9 years ago 
Demo-cube.c shows empty viewport in VS2010

Original comment by explomas...@gmail.com on 5 May 2013 at 1:57

GoogleCodeExporter commented 9 years ago 
Could you open a new issue please ?

Original comment by Nicolas.Rougier@gmail.com on 5 May 2013 at 2:03

GoogleCodeExporter commented 9 years ago 
Yes sure.Btw , wanted to ask you.Are you going to add features like paragraph 
alignment ?(Left ,Right ,Center) Would be very useful to have this calculation 
done by the lib. ;)

Original comment by explomas...@gmail.com on 5 May 2013 at 2:17