Compiling my old applications against of the newest ROOT I got:
In file included ... /rootdeb/include/TGLIncludes.h:17,
... /rootdeb/include/GL/glew.h:83:2: #error gl.h included before glew.h
... /rootdeb/include/GL/glew.h:86:2: #error glext.h included before glew.h
... /rootdeb/include/GL/glew.h:205:1: warning: "APIENTRY" redefined
......
/usr/include/GL/gl.h:99:1: warning: this is the location of the previous definitionWhat is the current (future) policy? Do I need to specify opengl-incdir OpenGL support, location of GL/gl.h
opengl-libdir OpenGL support, location of libGLalways to compile my old applciations ?
You should not include <GL/gl.h> yourself - just TGLIncludes - or, if there is include GL/gl.h in an external header, just include TGLIncludes before it.
We use GLEW now to be able to use full GL in compiled code and then do run-time detection of available functionality. This means we do not use system GL headers as they are often not very recent, especially on SLC4.
And no, you don’t have to specify location of GL includes, libs.
[quote=“matevz”]You should not include <GL/gl.h> yourself - just TGLIncludes[/quote]Yes, I did that a while ago. This is why I got that problem. I do use TGLIncludes. The later includes GLEW now. [quote=“matevz”] or, if there is include GL/gl.h in an external header, [/quote]That is the case[quote=“matevz”]just include TGLIncludes before it.[/quote]Thank you. I 've to find out which one to minimize the impact.
However, this is not just my personal issue . This could be a problem of all ROOT users who dare to start using OpenGL on its and follow my recommendation to use the TGLIncludes header.
Can you separate things?
Can you create the solution which is the backward compatible and the “old Root User” friendly
Since GLEW is now shipped with ROOT (but system version of GLEW is used if it is found during configure) the fact that TGLIncludes.h includes GLEW now, actually shields the users that were using TGLIncludes.h before.
As glew.h defines #define _gl_h #defineGL_H #define _glext_h #define _GLEXT_H #define _gl_ATI_h
and includes GL/glu.h, this protects against further inclusion of any GL headers. So, by moving the includes that import gl.h under TGLIncludes does not hurt and is backwards compatible.
In ROOT TGLIncludes are included 71 times and in AliEve (ALICE event display) only 5 times.
What I could do is to check if _gl_h (or equivalent) is already defined and then skip processing of TGLIncludes (or revert to old behaviour) and emit a warning, saying that this behaviour is deprecated. However, this might lead to linking errors, especially when using GL-2 and GL-extensions (glew wraps new gl functionality and gl extensions via functions pointers).
Out of interest, how many files would you have to change in your code and user code used in STAR (and other code that you are aware of)?
[quote=“matevz”] . . . .Since GLEW is now shipped with ROOT (but system version of GLEW is used if it is found during configure) the fact that TGLIncludes.h includes GLEW now, actually shields the users that were using TGLIncludes.h before.
As glew.h defines #define _gl_h #defineGL_H #define _glext_h #define _GLEXT_H #define _gl_ATI_h
and includes GL/glu.h, this protects against further inclusion of any GL headers. So, by moving the includes that import gl.h under TGLIncludes does not hurt and is backwards compatible.
[/quote]Ohh, it sounds the problem is slightly deeper. Let us assume there is some 3d party package that is represent by the shared lib. It uses the regular OpenGL internally and there is no simple way to recompile it. Can one use that package and the new ROOT features all together?
I found there are several issues with the new header files.
As soon as I set the header files in the “correct” order I can compile no RootCint dictionary for my applications as soon as the new header is included.
I am getting something like:/afs/rhic.bnl.gov/@sys/opt/star/sl44_gcc346/qt4.4/include/QtCore/qiodevice.h:183: error: redeclaration of C++ built-in type `int'
It suggests that some CPP flags are not correct, I did investigate the output of "root-config " and found no clue yet.
Is it expected ?
Why not? Is ftgl “3d party package”? Yes. Does it use gl headers or new TGLIncludes.h? It uses gl headers. Is it shared library? Yes. Can it be recompiled? Yes, as many times as you want. So, what is “slightly deeper” here?
Sorry for not replying earlier - didn’t get the notification mails.
First, I think it should be perfectly ok to use pre-compiled shared libraries using libGL - after all, libGLEW is linked against libGL. Anyway - let me know if there are any issues.
Second, looking at the file you mentioned (on afs/bnl), the line in question is:
183 typedef int Status;
The trouble comes from:
./X11/Xlib.h:#define Status int
included from glxew.h.
I’ll remove glxew.h from TGLIncludes.h and include it manually where it is really needed.
Sorry for the trouble.
[quote=“matevz”]The changes to TGLIncludes.h are in SVN now.
[/quote]Many thanks,
[quote=“matevz”]Out of interest, how many files would you have to change in your code and user code used in STAR (and other code that you are aware of)? [/quote]There is one place where I can replace the TGLInclude from ROOT with the regular GL/gl.h . I have spent some time investigating this “glew” issue and found it is a safe thing to do.
[quote=“tpochep”]Why not? Is ftgl “3d party package”? Yes. Does it use gl headers or new TGLIncludes.h? It uses gl headers. [/quote]How do you know that? The “ftgl” under ROOT uses whatever comes first.[quote=“tpochep”]Is it shared library? Yes. Can it be recompiled? Yes, as many times as you want. So, what is “slightly deeper” here?[/quote]Thank you for your example. Can you run the shell script below and show us the outcome?
void bla() {}
GLTEST
g++ -c root-config --cflags -Igraf2d/freetype/src/freetype-2.3.5/include glt.cxx
[/code]I hope the log can explain what I did mean speaking “deeper”.
Another reason to be concern:
[quote=“matevz”]As glew.h defines #define _gl_h [/quote]What we see above is a pure “hack”. The gl_h “include guard” can be defined but the gl.h header file only. en.wikipedia.org/wiki/Include_guard
On the other hand, I have spent some time investigating this “glew” issue and found it would be ridiculous and no value to make my code suddenly depend of the huge extra glew package
12192 LOC C code + 14836 LOC header
for the sake of the “extension loading” that I do not need to care about anyway.
(Did I understand correctly the “glew” is to be changed instantly to accommodate the new OpenGL interfaces and the various extensions ?)
So for me the correct solution is not to use TGLIncludes.h at all.
Anyway thank you very much for the fruitful discussion (my code works now) and sorry for the noise.
recommendation to use the TGLIncludes header.
place where I can replace the TGLInclude from ROOT with the regular GL/gl.h . I have spent some time investigating this “glew” issue and found it is a safe thing to do.