Hi
yes we haven't released the egl & gles libraries, you can use:
1. use eglGetProcAddress to get all of the required egl* gl* functions.
2. compile and link the test program with libGL.so

I have run the demo successfully after I remove the following code:
XChangeProperty (
      x_display, win,
      XInternAtom ( x_display, "_HILDON_NON_COMPOSITED_WINDOW", True ),
      XA_INTEGER,  32,  PropModeReplace,
      (unsigned char*) &one,  1);
it seems that XInternAtom ( x_display, "_HILDON_NON_COMPOSITED_WINDOW", True ) returns 0.

Created attachment 123 [details]
Modified Ninja EGL source (no graphics)

I gave your suggestion a try, and using eglGetProcAddress to get the other egl components is failing... I attached the source that should technically work on Ubuntu 10.10 (64-bit) with the 11.5 catalyst drivers.

Anyways, all calls using eglGetProcAddress segfault... even when trying to use a working function, like glActiveTexture.

as for compiling, it's extract and type make.

I had a quick investigation with your code, here are the problem:
1. you'd better use const char* EGL_DLL = "/usr/lib/libGL.so.1"; but not "/usr/lib/fglrx/libGL.so.1.2", with our driver, /usr/lib/libGL.so.1 is a symbol link to /usr/lib/fglrx/fglrx-libGL.so.1.2 (in order to support PX), so /usr/lib/fglrx/libGL.so.1.2 may not exist.

2. you should pass the Display* handle to eglGetDisplay. if ((ctx.eglDisplay = eglGetDisplay((NativeDisplayType)ctx.hInstance)) == EGL_NO_DISPLAY)

3. the function to load gl* is not correct, eg, you call eglGetProcAddress("\"glActiveTexture\"") to get glActiveTexture handle (same as others), you should change the code to:
#define IMPORT_FUNC(funcName) do {                                    \
        void *procAddress = (void *)eglGetProcAddress(#funcName); \
        if (procAddress == NULL) nRet = 0;                            \
        *((void **)&(funcName)) = procAddress; } while (0)

There may be other problems, I can not run the demo, because I don't have Ninja/NinjaComp.bmp, ./Ninja/ninja.sbm.
hope this can help you, you are welcome to give me any feedback.

(In reply to comment #3)
> I had a quick investigation with your code, here are the problem:
> 1. you'd better use const char* EGL_DLL = "/usr/lib/libGL.so.1"; but not
> "/usr/lib/fglrx/libGL.so.1.2", with our driver, /usr/lib/libGL.so.1 is a symbol
> link to /usr/lib/fglrx/fglrx-libGL.so.1.2 (in order to support PX), so
> /usr/lib/fglrx/libGL.so.1.2 may not exist.
> 

the file, /usr/lib/libGL.so.1 does not exist on my driver (installed with using the generated packages from the driver) so i am only using this hard link target for testing.

> 2. you should pass the Display* handle to eglGetDisplay. if ((ctx.eglDisplay =
> eglGetDisplay((NativeDisplayType)ctx.hInstance)) == EGL_NO_DISPLAY)
> 

Most of this code is what AMD put out to begin with. All i did was fix a few function defines. 

> 3. the function to load gl* is not correct, eg, you call
> eglGetProcAddress("\"glActiveTexture\"") to get glActiveTexture handle (same as
> others), you should change the code to:
> #define IMPORT_FUNC(funcName) do {                                    \
>         void *procAddress = (void *)eglGetProcAddress(#funcName); \
>         if (procAddress == NULL) nRet = 0;                            \
>         *((void **)&(funcName)) = procAddress; } while (0)
> 

This fails even when i try either of these:
    void *procAddress = eglGetProcAddress("\"eglGetError\""); 
    void *procAddress = eglGetProcAddress("\"glActiveTexture\""); 

Anyways, the define i used for the second half of the egl libs is as follows... 
#define IMPORT_FUNC_DLL(funcName)\
        printf("Loading EGL Function: %s\n",#funcName);\
        do { \

        void *procAddress = eglGetProcAddress("#funcName"); \

        if (procAddress == NULL) \
        { \
            printf("Failed to load... %s\n",#funcName);\
             return false; }\

        *((void **)&(funcName)) = procAddress;\
        } while (0)

This define is identical to the define you suggested, the only difference is a few print statements for debugging purposes... This define fails at the eglGetProcAddress on my system.

> There may be other problems, I can not run the demo, because I don't have
> Ninja/NinjaComp.bmp, ./Ninja/ninja.sbm.
> hope this can help you, you are welcome to give me any feedback.


These files are part of the AMD source code I did for this... so it's actually located here: (Link copied from the blog post mentioned in the first message)

http://developer.amd.com/samples/assets/egl_sample.zip

Created attachment 124 [details]
sytem report from atigensysteminfo.sh

Forgot my system report.

for the libGL.so, I am sorry I forgot that we had different location with recent release drivers, but it doesn't matter if you specify the correct one in any way.

for eglGetDisplay, the specification of egl said:The type and format of display id are implementation-specific, and it describes a specific display provided by the system EGL is running on. For example, an EGL implementation under X windows would require display id to be an X Display, while an implementation under Microsoft Windows would require display id to be a Windows Device Context.
And our implementation in linux need the X Display, because we need to communicate with XServer.

for eglGetProcAddress, I think that it is different between eglGetProcAddress("glActiveTexture") and eglGetProcAddress(""glActiveTexture""), if you use the latter, libGL will try to find the function "glActiveTexture", but not glActiveTexture.

after remove
XChangeProperty (
      ctx.hInstance, ctx.hWnd,
      XInternAtom ( ctx.hInstance, "_HILDON_NON_COMPOSITED_WINDOW", True ),
      XA_INTEGER,  32,  PropModeReplace,
      (unsigned char*) &one,  1);
and change the code to open NinjaComp.BMP instead of NinjaComp.bmp, I can run the demo in ubuntu10.10 with catalyst 11.5.

(In reply to comment #6)
> for the libGL.so, I am sorry I forgot that we had different location with
> recent release drivers, but it doesn't matter if you specify the correct one in
> any way.
> 
> for eglGetDisplay, the specification of egl said:The type and format of display
> id are implementation-specific, and it describes a specific display provided by
> the system EGL is running on. For example, an EGL implementation under X
> windows would require display id to be an X Display, while an implementation
> under Microsoft Windows would require display id to be a Windows Device
> Context.
> And our implementation in linux need the X Display, because we need to
> communicate with XServer.
> 
> for eglGetProcAddress, I think that it is different between
> eglGetProcAddress("glActiveTexture") and
> eglGetProcAddress(""glActiveTexture""), if you use the latter, libGL will try
> to find the function "glActiveTexture", but not glActiveTexture.
> 
> after remove
> XChangeProperty (
>       ctx.hInstance, ctx.hWnd,
>       XInternAtom ( ctx.hInstance, "_HILDON_NON_COMPOSITED_WINDOW", True ),
>       XA_INTEGER,  32,  PropModeReplace,
>       (unsigned char*) &one,  1);
> and change the code to open NinjaComp.BMP instead of NinjaComp.bmp, I can run
> the demo in ubuntu10.10 with catalyst 11.5.

I still gave that a try on my system. The problem is that when calling the function, eglGetProcAddress, my program segfaults without loading anything. Actually, This might be a platform bug. Is your system 32-bit or 64-bit. Mine is a 64-bit system and the program segfaults before i even get to the XChangeProperty lines...


to be exact, the output I get when I try to run the program is as follows...

ES dll library loaded.
Loading EGL Entry Points..
Loading EGL Function: eglGetProcAddress
Loading EGL Function: eglGetError
Segmentation fault


... The segmentation fault is when I attempt to use eglGetProcAddress to load the dll location for eglGetError.


Also, I'm running a Radeon HD5770 video card. I know this card has more than enough features for this task.

Actually, I'll make another update, I compiled the program as a 32-bit program and used the file, /usr/lib32/fglrx/libGL.so.1 to test the 32-bit program.

On this test, the program did not crash when running eglGetProcAddress. However, all of the other entry points failed.

No edit button makes for multiple posts on updates after investigations lol...

i found all of the egl exports, however, it's impossible to load them because they are located at in these files...  
/usr/lib/fglrx/dri/fglrx_dri.so
/usr/lib32/fglrx/dri/fglrx_dri.so
/usr/lib64/fglrx/dri/fglrx_dri.so

... however, when trying to load these libraries, the program immediately exits with a "Segmentation fault" at exit.

I think that your demo is a little different from mine. I have tested it in both 32 and 64bit system, the difference between 32 and 64bit system is only the libGL's location, in 32bit it is const char* EGL_DLL = "/usr/lib/libGL.so.1"; while in 64bit I changed to const char* EGL_DLL = "/usr/lib64/libGL.so.1"; And I think your system is different.

yes, the egl entry point is at fglrx_dri.so, but it is the same to use eglGetProcAddress from libGL.

the print info is:
ES dll library loaded.
Loading EGL Entry Points..
Loading EGL Function: eglGetProcAddress
Loading EGL Function: glActiveTexture
Loading EGL Function: eglGetError
Loading EGL Function: eglGetDisplay
Loading EGL Function: eglInitialize
Loading EGL Function: eglTerminate
Loading EGL Function: eglQueryString
Loading EGL Function: eglGetConfigs
Loading EGL Function: eglChooseConfig
Loading EGL Function: eglGetConfigAttrib
Loading EGL Function: eglCreateWindowSurface
Loading EGL Function: eglDestroySurface
Loading EGL Function: eglQuerySurface
Loading EGL Function: eglBindAPI
Loading EGL Function: eglQueryAPI
Loading EGL Function: eglWaitClient
Loading EGL Function: eglReleaseThread
Loading EGL Function: eglSurfaceAttrib
Loading EGL Function: eglBindTexImage
Loading EGL Function: eglReleaseTexImage
Loading EGL Function: eglSwapInterval
Loading EGL Function: eglCreateContext
Loading EGL Function: eglDestroyContext
Loading EGL Function: eglMakeCurrent
Loading EGL Function: eglGetCurrentContext
Loading EGL Function: eglGetCurrentSurface
Loading EGL Function: eglGetCurrentDisplay
Loading EGL Function: eglQueryContext
Loading EGL Function: eglWaitGL
Loading EGL Function: eglWaitNative
Loading EGL Function: eglSwapBuffers
Loading EGL Function: eglCopyBuffers
EGL Entry Points loaded.

Created attachment 126 [details]
my demo

my demo

I gave your demo a try, and here's the exact output:

For 64-bit binary:
using library: /usr/lib64/libGL.so.1
Library Symbolic link is to: /usr/lib64/fglrx/libGL.so.1.2
Output:
ES dll library loaded.
Loading EGL Entry Points..
Loading EGL Function: eglGetProcAddress
Loading EGL Function: glActiveTexture
Loading EGL Function: eglGetError
Segmentation fault

For 32-bit binary:
using library: /usr/lib32/libGL.so.1
Library Symbolic link is to: /usr/lib32/fglrx/libGL.so.1.2
output:
ES dll library loaded.
Loading EGL Entry Points..
Loading EGL Function: eglGetProcAddress
Loading EGL Function: glActiveTexture
Loading EGL Function: eglGetError
Failed to load... eglGetError
Failed to load EGL entrypoints

Created attachment 127 [details]
Exports for libGL.so and such

I think the problem is the exports for libGL, or some other bug with this.... just look at the other information i gathered on the libs.

I saw similar problems before that with a 32bit binary GetProcAddress returns NULL and with 64bit returns an invalid pointer, but that is mesa's code, and your system seems use AMD driver (from the exported symbols).
one possibilty is that your fglrx_dri.so is located at incorrect place, so may be libGL can not find it. the correct location should be /usr/lib/dri/, /usr/lib32/dri/, /usr/lib64/dri/

BTW: with Catalyst 11.5, it seems that our driver doesn't have libGL.so.1.2, it should be fglrx-libGL.so.1.2

(In reply to comment #14)
> I saw similar problems before that with a 32bit binary GetProcAddress returns
> NULL and with 64bit returns an invalid pointer, but that is mesa's code, and
> your system seems use AMD driver (from the exported symbols).
> one possibilty is that your fglrx_dri.so is located at incorrect place, so may
> be libGL can not find it. the correct location should be /usr/lib/dri/,
> /usr/lib32/dri/, /usr/lib64/dri/
> 
> BTW: with Catalyst 11.5, it seems that our driver doesn't have libGL.so.1.2, it
> should be fglrx-libGL.so.1.2

I added those links... anyways, for linking i have the following...
/usr/lib/dri/fglrx_dri.so -> /etc/alternatives/fglrx_dri
/usr/lib64/dri/fglrx_dri.so -> /etc/alternatives/fglrx_dri
/etc/alternatives/fglrx_dri -> /usr/lib/fglrx/dri/fglrx_dri.so
/usr/lib32/dri/fglrx_dri.so -> /usr/lib32/fglrx/dri/fglrx_dri.so

and with this, the segmentation faults occur... 

and as a side note, i added the link for... since this was missing.
/usr/lib32/dri/fglrx_dri.so -> /usr/lib32/fglrx/dri/fglrx_dri.so

also, i installed using the 11.5 driver...
File:
0a407ba5b7302239071a907e36a6934b  ati-driver-installer-11-5-x86.x86_64.run

Commands:
sh ati-driver-installer-11-5-x86.x86_64.run --buildpkg Ubuntu/maverick
sudo dpkg -i fglrx*.deb

I am sorry I have no idea, I just installed the driver with
sh ati-driver-installer-11-5-x86.x86_64.run
and I think it may be file location issue, but I don't know where is the problem

(In reply to comment #16)
> I am sorry I have no idea, I just installed the driver with
> sh ati-driver-installer-11-5-x86.x86_64.run
> and I think it may be file location issue, but I don't know where is the
> problem

This is more of a ubuntu/debian packaging issue then. I just installed using the install recommendation you made and the demo stopped having segmentation faults (without even rebooting).

libGL is installed in different places on different distributions. On Ubuntu the dynamic linker configuration is changed depending on which libGL is active. It's best to let the dynamic linker figure out the correct location of libGL. If you simply dlopen("libGL.so.1", flags), that should work on all systems.

(In reply to comment #18)
> libGL is installed in different places on different distributions. On Ubuntu
> the dynamic linker configuration is changed depending on which libGL is active.
> It's best to let the dynamic linker figure out the correct location of libGL.
> If you simply dlopen("libGL.so.1", flags), that should work on all systems.

The Dynamic linker does not always work correctly. I'd expect both the 32-bit and 64-bit versions to work without hassle, however, that's not the case.

When i install the system with the buildpkg option for ubuntu 10.10 amd64 i experience the problems listed in comment #7. 

I also modified the demo by changing the library that is loaded from a static lib to libGL.so.1 as you suggested, and it fails when attempting to use the function... eglGetProcAddress to load all the rest of the egl and gles flags.

Also, since this might be a distribution issue, I opened up a bug report for launchpad about the packager...

https://bugs.launchpad.net/ubuntu/829725


Tested with Catalyst 11.8 and the weird behavior continues.

I made a mistake on the link to the launchpad link in my last comment... Here's the corrected address..

https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/829725

(In reply to comment #18)
> libGL is installed in different places on different distributions. On Ubuntu
> the dynamic linker configuration is changed depending on which libGL is active.
> It's best to let the dynamic linker figure out the correct location of libGL.
> If you simply dlopen("libGL.so.1", flags), that should work on all systems.

Someone also tested sabayon 6 ( with catalyst 11.8 system packages ) and the bug is reproduced exactly as described in Comment #12

This message is a reminder that your bug is marked as Catalyst 11.4.

The current Catalyst version is 11.10.

Approximately 7 days from now the Bugzilla administrator will be removing the
11.4 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla
administrator provides this as a unofficial, free service to AMD customers, and
I like to keep my systems neat and tidy. If you would like to keep your bug
from being closed, please try a new Catalyst version and update the 'version'
field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will
change it for you.

Changing version number to 11.9 since the bug still appears in  Catalyst 11.9, and I'll test against 11.10 in the next couple of weeks.

this seems to be a platform specific issue, since we can't reproduce it here. 
can you step in the code and say why you get a segfault ?

(In reply to comment #24)
> this seems to be a platform specific issue, since we can't reproduce it here. 
> can you step in the code and say why you get a segfault ?


Yes, it is platform specific, but it's related to how the driver packages are done and the resulting setup. I've reproduced this bug for well over 6 months using the methods most end users will use for the driver ( namely from the included repository, although in my case I generate updated packages and install those ). I have found that the crash does not occur when I have the installer install the driver, however when I use the installer to generate packages the bugs appear. Just take a look at the library locations on the two major platforms I have experienced the bug ( Ubuntu Linux and Sabayon linux )


On Ubuntu 10.10 ( amd64, debian based): 
64-bit library location: /usr/lib64/fglrx/libGL.so.1.2
32-bit library location: /usr/lib32/fglrx/libGL.so.1.2


ubuntu 11.10 ( amd64, debian based, untested, but should still exist )
user space files: http://packages.ubuntu.com/oneiric/amd64/fglrx/filelist
Note the location of the libraries:
/usr/lib/fglrx/
/usr/lib32/fglrx/
/usr/lib64/fglrx/


sabayon ( amd64, gentoo based)
User space Package contents (Excludes kernel modules): https://packages.sabayon.org/show/ati-userspace,72007,sabayonlinux.org,amd64,5,standard/content#package-widget-show-what

Note where the libs are located:
/usr/lib32/opengl/ati/lib
/usr/lib64/opengl/ati/lib

can you do something like this to find the right path ?

system("LD_DEBUG=libs glxgears 2>&1 | grep libGL.so.1.2");

Created attachment 266 [details]
output of: LD_DEBUG=libs glxgears 2

Created attachment 267 [details]
Output of the openGL ES test program using: LD_DEBUG=libs  ./OpenGL_ES2x

Created attachment 268 [details]
output of the command: LD_DEBUG=libs  fglrxinfo

I know the last few files provide more information than required, but the information in these files shows how the libs are setup.

Created attachment 269 [details]
Updated sample that focuses solely on egl/GLES function loading.

Just did some more tests, and updated the sample program.

Using eglGetProcAddress to load functions: ( segfaults when used )
OpenGL ES Functions Loaded 0
EGL functions loaded 1 ( eglGetprocAddress via dlsym )

using glXGetProcAddress to load functions:
OpenGL ES Functions Loaded 97 ( all functions loaded )
EGL Functions 0 ( failed to find functions, but did not segfault)

Note: see GLES_EntryPoints.cpp for the modifications to only load the egl/gles functions.

Increasing to Catalyst 11.10, and on Ubuntu 11.10 ( Oneiric Ocelot )

Created attachment 293 [details]
LD_DEBUG on Catalyst 11.10 on Ubuntu 11.10

Contents of the command:

LD_DEBUG=libs ./OpenGL_ES2x 


also, on a side note, this uses the Recommended method that most users would use... Installed from generated packages. glxgears, fgl_glxgears and fglrxinfo all work as they are supposed to.

Created attachment 294 [details]
Updated Test program.

Updated test program to use recommend library loading ( libGL.so.1 ), and bundled in the khronos headers for egl, and gles2 so that the testing can be done on a cleaner setup. Also, this updated program does not include the Ninja data.


Note: This bug occurs when using the simplest methods of installation for the end user ( Install via the Package manager on Ubuntu and on sabayon linux ). This can also be reproduced by downloading the package from the amd website, and then passing the '--buildpkg' flag to generate the packages for the package manager.

The issue still persists on Catalyst 11.12, however I did manage to find out the issue permanently. 

The dynamic loader was trying to open up the libGL.so.1.2 file and was failing. The failure was due to the fact that libGL.so.1.2 was not in any of the search paths.

However, The closest existing file that i could find was libGL.so.1 and this file is part of the interface information given for linux by khronos ( see: http://www.opengl.org/registry/ABI/ ).

The temporary fix i have is to create a symbolic link from libGL.so.1 to libGL.so.1.2 and then run the demo. This Temporary solution fixed the issues of a segmentation fault with the driver Immediately, and this hints that the issue is about the OpenGL ES/EGL features not working as defined by the OpenGL ABI Specification that was mentioned before.

Updating the Version to 12.4... This is still broken... This time i installed the OpenGL ES SDK from:
http://developer.amd.com/samples/sampleapps/pages/AMDOpenGLESSDK.aspx

And I ran the Sample program on Linux Mint 12 ( Ubuntu oneiric based), and the sample has a segmentation fault in both 32-bit and 64-bit modes when trying to call eglGetDisplay.

32-Bit Backtrace: ( Compiled and linked using the -m32 flag )
==================================================================
(gdb) r
Starting program: /home/kenney/gles_sdk/sample/bin/GLESSample.32 
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xf7e7b88b in eglGetDisplay () from ../../x86/libEGL.so.1
#2  0x0804f008 in ?? ()
#3  0x0804a600 in main (argc=1, argv=0xffffd834) at main.cpp:481



64-bit Backtrace:
===================================================
(gdb) r
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff445820b in ?? () from /usr/lib/dri/fglrx_dri.so
#2  0x00007ffff4357e69 in ?? () from /usr/lib/dri/fglrx_dri.so
#3  0x00007ffff503752a in ?? () from /usr/lib/dri/fglrx_dri.so
#4  0x00007ffff5c5fb0c in ?? () from /usr/lib/dri/fglrx_dri.so
#5  0x00007ffff5cc7782 in ?? () from /usr/lib/dri/fglrx_dri.so
#6  0x00007ffff7ec7a00 in ?? ()
#7  0x0000000000000001 in ?? ()
#8  0x00007fffffffe6f8 in ?? ()
#9  0x00007ffff4329323 in ?? () from /usr/lib/dri/fglrx_dri.so
#10 0x00007ffff7ec7688 in ?? ()
#11 0x00007ffff7deab0b in ?? () from /lib64/ld-linux-x86-64.so.2
#12 0x00007ffff7deac2f in ?? () from /lib64/ld-linux-x86-64.so.2
#13 0x00007ffff7deee63 in ?? () from /lib64/ld-linux-x86-64.so.2
#14 0x00007ffff7dea9c6 in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x00007ffff7def3aa in ?? () from /lib64/ld-linux-x86-64.so.2
#16 0x00007ffff6c4ef26 in dlopen_doit (a=0x7fffffffe3c0) at dlopen.c:67
#17 0x00007ffff7dea9c6 in ?? () from /lib64/ld-linux-x86-64.so.2
#18 0x00007ffff6c4f52f in _dlerror_run (operate=0x7ffff6c4eec0 <dlopen_doit>, args=0x7fffffffe3c0) at dlerror.c:164
#19 0x00007ffff6c4efc1 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:88
#20 0x00007ffff7eceed0 in ?? () from ../../x86-64/libEGL.so.1
#21 0x00007ffff7ecfc8d in eglGetDisplay () from ../../x86-64/libEGL.so.1
#22 0x0000000000402344 in Setup (ctx=...) at main.cpp:214
#23 0x0000000000402df6 in main (argc=1, argv=0x7fffffffe6f8) at main.cpp:481

Created attachment 440 [details]
Various Output Results pertaining to Catalyst 12.4

Contains the LD_DEBUG Flags for the 32 and 64-bit demos, and the LD_DEBUG flag for the Old Sample that was working... I also made sure to add the updated atigensysteminfo.sh results to this compressed archive.

I managed to get the sample running with the dgles2 software, and found what some illegal code is improperly initialized on linux.

nativewin_x11.cpp line 90 leads to the call of glviewport outside of a context. This is illegal function calls under the OpenGL ES specs, and OpenGL specs because no context has truly been set. 

The best solution for this is to make this call after the initial call to eglMakeCurrent. In other words at line 302 of main.cpp.


The sample I checked was this: http://developer.amd.com/samples/sampleapps/pages/AMDOpenGLESSDK.aspx


As for the dgles software, I used the code for gles-libs found at meego's wiki ( see: http://wiki.meego.com/ARM/Meego_on_Qemu )

as for what i did, I downloaded this git repository:
git://gitorious.org/qemu-maemo/gles-libs.git

Built, and installed using:
./configure --enable-glx --enable-x11 --prefix=/opt/dgles2 
make
sudo make install

As for making use of these libs, there was no real changes except for mentioning the above issue, and to point the dynamic library loading to use the library folder in /opt/dgles2.

(In reply to comment #37)
> I managed to get the sample running with the dgles2 software, and found what
> some illegal code is improperly initialized on linux.
> 
> nativewin_x11.cpp line 90 leads to the call of glviewport outside of a context.
> This is illegal function calls under the OpenGL ES specs, and OpenGL specs
> because no context has truly been set. 
> 
> The best solution for this is to make this call after the initial call to
> eglMakeCurrent. In other words at line 302 of main.cpp.
> 
> 
> The sample I checked was this:
> http://developer.amd.com/samples/sampleapps/pages/AMDOpenGLESSDK.aspx
> 
> 
> As for the dgles software, I used the code for gles-libs found at meego's wiki
> ( see: http://wiki.meego.com/ARM/Meego_on_Qemu )
> 
> as for what i did, I downloaded this git repository:
> git://gitorious.org/qemu-maemo/gles-libs.git
> 
> Built, and installed using:
> ./configure --enable-glx --enable-x11 --prefix=/opt/dgles2 
> make
> sudo make install
> 
> As for making use of these libs, there was no real changes except for
> mentioning the above issue, and to point the dynamic library loading to use the
> library folder in /opt/dgles2.

Thanks for the info, Ken!
I have submitted a fix to our internal code base per your suggestion, and hopefully the fix will be made public soon.

The OpenGL ES support is still broken in 12.6. This really should be fixed.

Anyways, The test system as always uses the distributions "Recommended Install" method where fglrx is installed from a package. This test system is linux Mint 13 ( uses the Ubuntu/precise buildpackage), and the demo crashes.

Anyways, The issue is still hard coded library paths.

A temporary solution for ubuntu is to create the following symbolic links on an amd64 install:
sudo ln -s /usr/lib64/fglrx/libGL.so.1 /usr/lib64/libGL.so
sudo ln -s /usr/lib64/fglrx/libGL.so.1 /usr/lib64/libGL.so.1
sudo ln -s /usr/lib64/fglrx/libGL.so.1 /usr/lib64/libGL.so.1.2

Now  for 32-bit binaries on a 64-bit os, this should fix the issue, but it does not:
sudo ln -s /usr/lib32/fglrx/libGL.so.1 /usr/lib32/libGL.so
sudo ln -s /usr/lib32/fglrx/libGL.so.1 /usr/lib32/libGL.so.1
sudo ln -s /usr/lib32/fglrx/libGL.so.1 /usr/lib32/libGL.so.1.2

And as for x86 install, the following commands should work on Ubuntu:
sudo ln -s /usr/lib/fglrx/libGL.so.1 /usr/lib/libGL.so
sudo ln -s /usr/lib/fglrx/libGL.so.1 /usr/lib/libGL.so.1
sudo ln -s /usr/lib/fglrx/libGL.so.1 /usr/lib/libGL.so.1.2


As for a long term solution, I would say that making a major note that hard coding library paths is a extremely bad idea, because the hard coded 

also, on an interesting note, the OpenGL ES implementation fails to acknowledge multi-head setups properly. I use a setup where there is two main displays, namely :0.0 and :0.1. When i launch a OpenGL ES application on display :0.1 the rendering appears on display :0.0... This is completely incorrect behavior because the x11 window is on display :0.1 


Also, Lastly, I follow the community guidelines for package installation located at:
http://wiki.cchtml.com/index.php/Ubuntu_Oneiric_Installation_Guide

I would like to second the request that this be fixed.  I've spent 3 days trying to figure this out until I stumbled upon this thread.  Adding the sym links to /usr/lib as suggested by Ken p. fixed the problem for me.

I'm running Ubuntu 12.04 32bit.

dave

PS, Thanks for releasing the ES2 drives.  I traded my Nvidia card for a AMD just to have them. ;^)

This issue still persists with Catalyst 12.6 release. On a 64-bit system, Both 32-bit and 64-bit builds of the sample crash when calling eglGetDisplay()

Created attachment 531 [details]
latest results ( one working and other failing )

I finally tracked down the issue. This is a packaging issue, and this probably should be fixed in later releases.

When trying to use the OpenGL ES demo on Ubuntu 12.04 ( Linux Mint 13), the program will segfault. The issue is that the following libraries are not found...
libatiadlxx.so
libatiuki.so.1

The fix is to modify the environmental variable, LD_LIBRARY_PATH, such that these libraries are in the path. This means that on Ubuntu 12.04 and linux mint 13 the ld library path must be configured so that the following path is in the path list (on 32-bit installs):
/usr/lib/flgrx

For 64-bit installs you use:
/usr/lib/flgrx
/usr/lib32/flgrx

Any progress on this?  There has been no update for almost a year now.

This message is a reminder that your bug is marked as Catalyst 12.6.

The current legacy Catalyst version is 13.1.
The current Catalyst version is 13.4.
The current Catalyst beta version is 13.8.

Approximately 7 days from now the Bugzilla administrator will be removing the 12.6 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla administrator provides this as a unofficial, free service to AMD customers, and I like to keep my systems neat and tidy. If you would like to keep your bug from being closed, please try a new Catalyst version and update the 'version' field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will change it for you.

Still an issue on 13.6

This message is a reminder that your bug is marked as Catalyst 13.4.

The current legacy Catalyst version is 13.1.
The current Catalyst version is 13.12.
The current Catalyst beta version is 14.2.

Approximately 7 days from now the Bugzilla administrator will be removing the 13.4 version. At that time your bug will be CLOSED as WONTFIX.

Bug Reporter: Thank you for reporting this issue. However, the Bugzilla administrator provides this as a unofficial, free service to AMD customers, and I like to keep my systems neat and tidy. If you would like to keep your bug from being closed, please try a new Catalyst version and update the 'version' field if the issue still occurs.

If you are unable to update the version, please make a comment and someone will change it for you.

This bug is being closed due to the 'version' being 13.4 after 13 days of the previous closure notice.

Thank you for your bug report.