Opened 15 years ago
Closed 14 years ago
#5824 closed bug (fixed)
gcc4 built opengl application fails to find an opengl renderer
| Reported by: | aldeck | Owned by: | phoudoin |
|---|---|---|---|
| Priority: | high | Milestone: | R1 |
| Component: | Kits/OpenGL Kit | Version: | R1/alpha1 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
gcc4 built opengl application fails to find an opengl renderer.
eg: a gcc4 built GLTeapot will display the "No OpenGL renderer available" message.
As syslog shows, the runtime loader can't find the renderer addon.
Puting a gcc4 built "Mesa Software Renderer" alongside the gcc2 one in /boot/system/add-ons/opengl worked for me (whatever the name of both, to my surprise). This allowed me to run gcc4 and gcc2 opengl dependent apps.
Haiku hrev36421 trunk gcc2/4 hybrid
Here's my experience, not sure about the proper fix.
Change History (5)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:3 by , 14 years ago
| Priority: | normal → high |
|---|
comment:4 by , 14 years ago
| Status: | assigned → in-progress |
|---|
comment:5 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | in-progress → closed |
Note:
See TracTickets
for help on using tickets.
I guess we break GLRenderer or GLDispatcher ABI somewhere, which leads to gcc2 Mesa Software Renderer failure at runtime link loading stage.
Regarding your surprise, the built-in GLRendererRoster in libGL.so search every */add-ons/opengl add-ons and currently select the first one he succeed to load. The add-on name doesn't matter, indeed.