GCC Errot when i compil the Vincent Source code on Linux

…/…/src/ContextTexture.cpp: In function EGL::Color *{unnamed}::ExtractColorPalette (const U8 *&, {unnamed}::PaletteFormat, unsigned int)': ../../src/ContextTexture.cpp:890: could not convert {}’ to
{unnamed}::RGB2Color &' ../../src/ContextTexture.cpp:877: in passing argument 4 of {unnamed}::CreatePalette (const U8 *&, unsigned int, EGL::Color *,
SrcAccessor &) [with SrcAccessor = {unnamed}::RGB2Color]’
…/…/src/ContextTexture.cpp:894: could not convert {}' to {unnamed}::RGBA2Color &’
…/…/src/ContextTexture.cpp:877: in passing argument 4 of
{unnamed}::CreatePalette (const U8 *&, unsigned int, EGL::Color *, SrcAccessor &) [with SrcAccessor = {unnamed}::RGBA2Color]' ../../src/ContextTexture.cpp:898: could not convert {}’ to
{unnamed}::RGB5652Color &' ../../src/ContextTexture.cpp:877: in passing argument 4 of {unnamed}::CreatePalette (const U8 *&, unsigned int, EGL::Color *,
SrcAccessor &) [with SrcAccessor = {unnamed}::RGB5652Color]’
…/…/src/ContextTexture.cpp:902: could not convert {}' to {unnamed}::RGBA44442Color &’
…/…/src/ContextTexture.cpp:877: in passing argument 4 of
{unnamed}::CreatePalette (const U8 *&, unsigned int, EGL::Color *, SrcAccessor &) [with SrcAccessor = {unnamed}::RGBA44442Color]' ../../src/ContextTexture.cpp:906: could not convert {}’ to
{unnamed}::RGBA55512Color &' ../../src/ContextTexture.cpp:877: in passing argument 4 of {unnamed}::CreatePalette (const U8 *&, unsigned int, EGL::Color *,
SrcAccessor &) [with SrcAccessor = {unnamed}::RGBA55512Color]’
make[1]: *** [ContextTexture.o] Error 1
make[1]: Leaving directory `/home/seongnam_oh/ogles/projects/linux’
make: *** [GLES] Error 2
[seongnam_oh@localhost linux]$

=============================================
This problem is happend with GCC 2.96.
Who can help me ?
As far as i know, this ContextTexture.c file was compiled with Embedded VC.
the message looks like “namespace” problem. but that is not real problem, the real problem is template problem.
:mad: :mad: :mad: :confused: :confused:

Unfortunately I do not have a version of gcc-2.96. The file compiles successfully using
gcc version 2.9-psion-98r2 (Symbian build 540).

Can you isolate the issue (i.e. finding the minimum subset of the file that reproduces the, or maybe just the first of the problems)?

Looking over the code: Maybe the implementation of anonymous namespaces in broken in this compiler build. You might want to try to comment out all


declarations and lift all declarations to global scope. There is a rule in C++ that a sequence of anonymous namespaces gets collected into a single namespace. Maybe the code in the second namespace does not see code coming from the first. If that’s the case, then moving the code into a single namespace would be the correct resolution.

Let me know.

  • HM

PS: There is actually a Support Request Page and a Help Discussion Forum for Vincent hosted on sourceforge.

[ July 16, 2004: Message edited by: Hans-Martin Will ]

BTW, what system are you exactly targeting?

Just curious,
HM

could you send me your e-mail address ?
i am going to send you my comipiled source tree. you may check with this problem with evey compiler [ GCC , X86 ].

before i load previous message i have tried your suggetion. it had still that problem.

Regards,
SeongNam.

Thanks. You can reach me through this forum (private message) or through sourceforge.

I probably won’t have the time to play with gcc 2.96 nor do want to change any of the infrastructure settings on my development machine at this point. If those few functions are indeed the only problem, then just do the expansion of the templates manually.

Have you tried Klimt? It has been successfully ported to a couple of Linux platforms. It’s use of templates is much more fundamental than Vincent’s.

Good luck,
HM

GCC 2.96 has never been released as a production build by gnu, see here.
Have you considered up/downgrading to one of the released builds from this list?

Cheers,
HM

i don’t know how to attach the zipped file through private mail board.
my e-mail address is seongnam.oh@samsung.com.
could you send me a mail, that times, i am gonna send the source files and make environments with mail-attached function.
i compiled the other files successfully. the only one have has this problem.

thanks.

OK. I have solved this problem by changing a line in source code.

<<<<<< Original Source >>>>>>>>

template &lt;class SrcAccessor&gt; inline void CreatePalette(const U8 *& data,
	size_t numberOfColors, Color * colors, const SrcAccessor& accessor) {
	for (size_t index = 0; index &lt; numberOfColors; ++index) {
		colors[index] = accessor(data);
	}
}

======================================
<<<<<< modified source >>>>>>>>

template &lt;class SrcAccessor&gt; inline void CreatePalette(const U8 *& data,
	size_t numberOfColors, Color * colors, const SrcAccessor& ) {
	SrcAccessor accessor;
	for (size_t index = 0; index &lt; numberOfColors; ++index) {
		colors[index] = accessor(data);
	}
}

========================================

Great. So it is just a simple compiler bug.
I’ll adjust the code though.

Thanks,
HM

I have removed “namespace” relevent code in your souce code, the purpose of the keyword is to prevent function/variable’s scope missing.
but it can be protected by using C++ Class and static keyword, then Nomally, Generally, Embedded programmer doesn’t use that keyword.
because, Embedded programmer has always making strict coding in mind.

do i have any problem when i remove this keyword ?

i have successfully compiled the sources, but didn’t have a chance to test this code. because i am developing egl relevent code for fbdev.

Whatever works for you…

So what platform were you targeting again?

Cheers,
HM

[ July 19, 2004: Message edited by: Hans-Martin Will ]

  • Embedded Linux Platform. [ Mips Core : 300 MHz ]

I have finished FBDEV egl porting, and I have tested this code whether the module has problem or not.

but i got a runtime error message like following. do you have any idea ?

is this also GCC bug ? overriding problem ?

[root@localhost linux]# ./hello
FrameBuffer = 0x40854000
Segmentation fault (core dumped)
[root@localhost linux]# gdb ./hello core
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i686-pc-linux-gnu”…
Core was generated by `./hello’.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/libdl.so.2…done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2…done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x0806541f in FractionalColor: :operator= (this=0x69c, other=@0xbffffaf0)
at …/…/src/FractionalColor.h:94
94 r = other.r;
(gdb) bt
#0 0x0806541f in FractionalColor: :operator= (this=0x69c, other=@0xbffffaf0)
at …/…/src/FractionalColor.h:94
#1 0x08051544 in Context::ClearColorx (this=0x0, red=0, green=0, blue=0,
alpha=0) at …/…/src/Context.cpp:260
#2 0x08051f80 in Context::ClearColor (this=0x0, red=0, green=0, blue=0,
alpha=0) at …/…/src/ContextFloat.cpp:50
#3 0x08049b9c in glClearColor (red=0, green=0, blue=0, alpha=0)
at …/…/src/gl.cpp:68
#4 0x080499ff in init () at hello.c:109
#5 0x08049a74 in main (argc=1, argv=0xbffffc0c) at hello.c:129
Current language: auto; currently c++
(gdb)

this=0x0

i.e. you haven’t set the rendering context when you call into clear. I still haven’t decided yet how to best catch these mistakes without adding too much runtime overhead.

This is tracked as bug
960546 “Validate all error conditions for all gl… entry points”

  • HM

BTW, you said MIPS? This means you’ll have to rewrite the code generation backend to support this processor (emit.c). Right now Vincent is supporting only ARM and derivates (StrongARM, XScale, OMAP).

Just in case you weren’t aware of this.

  • HM

I used only src/ files to make OpenGLES Library.

Then, the souce tree looks like theses.

/ogles
/project/linux/makefile
<makefiles>
/src
<your souces>
/src/linux
<framebuffer driver & egl souces>
/test
<test application : hello.c>

that’s all directory structure.
I didn’t use Jit/ARM relevent code.
then, i modified FunctionCache relevent part of souceses in /src directory.

do i need ay other files in /ARM or /CordGen directory ?

Regards,
SeongNam.

Bellowing is first sample program to test OpenGLES Library.

could you check the problem point ?

Regards,
SeongNam.

/*

  • hello.c
  • This is a simple, introductory OpenGL program.
    */
    #include “egl.h”

// OpenGL variables
EGLDisplay g_display; // EGL display
EGLSurface g_surface; // EGL rendering surface
EGLContext g_context; // EGL rendering context

#define FALSE 0
#define TRUE 1

int InitOpenGL(void) {
// Initialize OGL

EGLint major, minor;
EGLConfig configs[10];
EGLint matchingConfigs;
EGLint attribList[] = { 0 };	// extend this
EGLConfig config;

g_display = 0;
if (!eglInitialize(g_display, &major, &minor)) {
	return FALSE;
}

if (!eglChooseConfig(g_display, attribList, &configs[0], 10, &matchingConfigs)) {
	return FALSE;
}

if (matchingConfigs &lt; 1) {
	return FALSE;
}

config = configs[0];	// pick any
g_surface = eglCreateWindowSurface(g_display, config, 0, attribList);

// test for error 

g_context = eglCreateContext(g_display, config, 0, attribList);
eglMakeCurrent(g_display, g_surface, g_surface, g_context);

return TRUE;

}

void display(void)
{
/* clear all pixels */
glClear (GL_COLOR_BUFFER_BIT);

/* draw white polygon (rectangle) with corners at

  • (0.25, 0.25, 0.0) and (0.75, 0.75, 0.0)
    */
    glColor4f (1.0, 1.0, 1.0, 1.0);
    glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

/* don’t wait!

  • start processing buffered OpenGL routines
    */
    glFlush ();
    }

void init (void)
{
const static GLfloat v[] = {
0.25, 0.25, 0.0,
0.75, 0.25, 0.0,
0.25, 0.75, 0.0,
0.75, 0.75, 0.0
};
/* select clearing color */
glClearColor (0.0, 0.0, 0.0, 0.0);

/* initialize viewing values */
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrthof(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);
glVertexPointer(3, GL_FLOAT, 0, v);
glEnableClientState(GL_VERTEX_ARRAY);
}

/*

  • Declare initial window size, position, and display mode

  • (single buffer and RGBA). Open window with “hello”

  • in its title bar. Call initialization routines.

  • Register callback function to display graphics.

  • Enter main loop and process events.
    /
    int main(int argc, char
    * argv)
    {
    InitOpenGL();
    init();
    display();
    eglSwapBuffers(0,0);
    while(1) {};

    return 0; /* ANSI C requires main to return int. */
    }

I see. It might be a little bit slow in the end, because the C++ rasterizer is really more meant a debugging aid when you run your code from within the emulator. To get a proper throughput, the JIT is an essential part of the architecture. So for my own projects, I’m using the reference implementation of OpenGL ES on the desktop, and Vincent on the devices.

But, I guess, you’ll see what you get out of it.

Cheers,
HM

In the Context Management file, WindowsCE System use Tls…(…) API to manage the Current & Old context.
but Epoc case, the system doesn’t have that kind of mechanism.
How could you solve this issue in Epoc System ?
As you mentioned, Upper Problem was occured by NULL data passing to under layer.
the NULL data is Context which comes from GetCurrentContext() API calling.

Regards,
SeongNam.

void Context :: SetCurrentContext(Context * context) {

//extern DWORD s_TlsIndexContext;

Context * oldContext = GetCurrentContext();

if (oldContext != context) {

	if (oldContext != 0)
		oldContext-&gt;SetCurrent(false);

	if (context != 0)
		context-&gt;SetCurrent(true);
}

}

Context * Context :: GetCurrentContext() {

return reinterpret_cast&lt;EGLContext&gt; (0);

}

I see, you pulled the code from the branch HEAD. That’s work in progress, if you update again you will see that this code has changed.

In the meantime, this code looks like


which probably won’t run on Linux either. So, that’s the point where you will have to start figuring things out yourself. How about creating a new directory alongside of WinCE and Ecos named “Linux” (or whatever describes your platform best) and mainting modified versions of egl.cpp, Surface.[h/cpp] etc. there?

  • HM

[ July 20, 2004: Message edited by: Hans-Martin Will ]

:slight_smile: :wink:
I saw result of simple.c on my FB screen.
BTW. I am going to touch some sources to support RGBA8 mode.
I have looked Config.cpp. is that all to change graphic resolution & color management ?

Regards,
SeongNam.