PDA

View Full Version : GCC Errot when i compil the Vincent Source code on Linux



seongnam
07-16-2004, 07:01 AM
../../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:

hmwill
07-16-2004, 06:49 PM
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 (http://sourceforge.net/tracker/?atid=583373&group_id=87506&func=browse) and a Help Discussion Forum (http://sourceforge.net/forum/forum.php?forum_id=300095) for Vincent hosted on sourceforge.

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

hmwill
07-16-2004, 07:00 PM
BTW, what system are you exactly targeting?

Just curious,
HM

seongnam
07-18-2004, 05:46 PM
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.

hmwill
07-18-2004, 07:44 PM
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

hmwill
07-18-2004, 07:55 PM
GCC 2.96 has never been released as a production build by gnu, see here (http://gcc.gnu.org/releases.html#timeline).
Have you considered up/downgrading to one of the released builds from this list?

Cheers,
HM

seongnam
07-18-2004, 10:47 PM
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.

seongnam
07-18-2004, 11:58 PM
OK. I have solved this problem by changing a line in source code.
======================================
<<<<<< Original Source >>>>>>>>

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

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

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

hmwill
07-19-2004, 05:42 AM
Great. So it is just a simple compiler bug.
I'll adjust the code though.

Thanks,
HM

seongnam
07-19-2004, 05:39 PM
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.

hmwill
07-19-2004, 08:07 PM
Whatever works for you...

So what platform were you targeting again?

Cheers,
HM

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

seongnam
07-19-2004, 11:17 PM
- 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)

hmwill
07-19-2004, 11:36 PM
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

hmwill
07-19-2004, 11:40 PM
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

seongnam
07-20-2004, 12:30 AM
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.

seongnam
07-20-2004, 12:35 AM
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 < 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. */
}

hmwill
07-20-2004, 12:38 AM
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

seongnam
07-20-2004, 02:33 AM
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->SetCurrent(false);

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


Context * Context :: GetCurrentContext() {

return reinterpret_cast<EGLContext> (0);
}

hmwill
07-20-2004, 03:51 AM
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 ]

seongnam
07-20-2004, 03:03 PM
:) ;)
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.

hmwill
07-20-2004, 05:41 PM
Congratulations!

However, adding support for RGBA8 surfaces is going to be a bit more involved; if it were that easy as you propose, a second configuration with these settings would probably already exist. ;)

There are a bunch of areas which you will have to adapt:
- The rendering surface itself will need to be different (currently it's RGB565 + A8)
- In ContextTexture, you will want to change the internal format for RGB textures to RGB8
- In ContextTexture, you will need to adjust the functions CopySurfacePixels() to the new format.
- In Rasterizer::Fragment, you will need to adjust the code were you write to the surface
- You might need to adjust the color buffer pointer in Rasterizer::RasterInfo to point to 32-bit values

And probably a couple of places more... As I understand, you are not interested in using the JIT, which would complicate things further, as all internal intermediate values during texture modulation and blending are optimized for RGB565 representation.

I am probably not going to address these issues by myself, because my primary platform is Windows Mobile, and the current configuration is the best for this platform.

However, even for Symbian Series 60 devices (n-Gage, SX-1, 3650) a different surface (in this case: 4444) can be advantageous. Given I get volunteers, I could facilitate the addition of additional rendering surface formats.

Cheers,
HM

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

seongnam
07-21-2004, 10:09 PM
I have chaged recommanded sources and i have a one rectangle. when i use 32bit FB and 16bit(565 Pixel format ), i saw 2 small rectangle like side by side.
but color is not correct.
in my understanding, RGBA8 mode use real RGBA order, but FB use ARGB then i have to change pixel operation part in sources.

is there any special place to change from RGBA8 to ARGB8 ?

Regards,
SeongNam. ;)

hmwill
07-22-2004, 05:45 AM
add additional From... and To... calls to
Color and FractionalColor

If you want to support texture using this format:
add
Color2ARGB and ARGB2Color to ContextTexture
Add a new internal format constant to RasterizerState and hook it up as base internal format for RGBA
Add this new format into the switches of CopyPixels and CopySurfacePixels so that the transformation will be done automatically as you push/pull data in/out of the context.

- HM