Menu
▾
▴
mesa3d-users
|
From: Andreas P. <and...@gm...> - 2010-03-11 14:06:38
|
Hi,
I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
I have two rather strange problems using egl. I have implemented a
egl/es2/libX11 based renderer shared object file. The shared object
file gets loaded and initialized using dlopen/dlsym. Then when the
renderer is supposed to initialize EGL, and to create a window I run
into runtime symbol lookup errors.
./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
undefined symbol: _eglInitDriverFallbacks
When I add the following to the makefiles - it seems to work.
--- a/src/gallium/winsys/drm/swrast/egl/Makefile
+++ b/src/gallium/winsys/drm/swrast/egl/Makefile
@@ -3,7 +3,7 @@ include $(TOP)/configs/current
EGL_DRIVER_NAME = swrast
EGL_DRIVER_SOURCES = dummy.c
-EGL_DRIVER_LIBS =
+EGL_DRIVER_LIBS = -lEGL
EGL_DRIVER_PIPES = \
$(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
Then the eglInitialize() command still fails because of something else.
When I run the application with the following settings:
EGL_DRIVER=egl_x11_swrast
EGL_SOFTWARE=1
EGL_DISPLAY=x11
EGL_LOG_LEVEL=debug
I get:
libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
libEGL info: use software fallback
libEGL warning: No supported client API
libEGL debug: no state tracker supports config 0x21
... till ...
libEGL debug: no state tracker supports config 0x98
libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
add configs)
The demos in mesa/progs/egl give me the same output. While the demos
in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
wrong?
regards
Andreas Pokorny
|
|
From: Chia-I Wu <ol...@gm...> - 2010-03-11 15:58:13
|
On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
<and...@gm...> wrote:
> Hi,
>
> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
>
> I have two rather strange problems using egl. I have implemented a
> egl/es2/libX11 based renderer shared object file. The shared object
> file gets loaded and initialized using dlopen/dlsym. Then when the
> renderer is supposed to initialize EGL, and to create a window I run
> into runtime symbol lookup errors.
>
> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
> undefined symbol: _eglInitDriverFallbacks
It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen
who?). Do you have a sample code that reproduces your setup or the issue?
> When I add the following to the makefiles - it seems to work.
>
> --- a/src/gallium/winsys/drm/swrast/egl/Makefile
> +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
> @@ -3,7 +3,7 @@ include $(TOP)/configs/current
>
> EGL_DRIVER_NAME = swrast
> EGL_DRIVER_SOURCES = dummy.c
> -EGL_DRIVER_LIBS =
> +EGL_DRIVER_LIBS = -lEGL
>
> EGL_DRIVER_PIPES = \
> $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
>
> Then the eglInitialize() command still fails because of something else.
>
> When I run the application with the following settings:
> EGL_DRIVER=egl_x11_swrast
> EGL_SOFTWARE=1
> EGL_DISPLAY=x11
> EGL_LOG_LEVEL=debug
>
> I get:
>
> libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
> libEGL info: use software fallback
> libEGL warning: No supported client API
> libEGL debug: no state tracker supports config 0x21
> ... till ...
> libEGL debug: no state tracker supports config 0x98
> libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
> add configs)
> The demos in mesa/progs/egl give me the same output. While the demos
> in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
> wrong?
>From which directory do you build your libGL? You need to use the one from
src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
Have a look at the OpenGL section in docs/egl.html.
--
ol...@Lu...
|
|
From: Keith W. <ke...@vm...> - 2010-03-11 16:14:48
|
This may be related to the attached patch. Please let me know if this
improves things & I'll commit
Keith
On Thu, 2010-03-11 at 07:57 -0800, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
> <and...@gm...> wrote:
> > Hi,
> >
> > I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
> >
> > I have two rather strange problems using egl. I have implemented a
> > egl/es2/libX11 based renderer shared object file. The shared object
> > file gets loaded and initialized using dlopen/dlsym. Then when the
> > renderer is supposed to initialize EGL, and to create a window I run
> > into runtime symbol lookup errors.
> >
> > ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
> > undefined symbol: _eglInitDriverFallbacks
> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen
> who?). Do you have a sample code that reproduces your setup or the issue?
> > When I add the following to the makefiles - it seems to work.
> >
> > --- a/src/gallium/winsys/drm/swrast/egl/Makefile
> > +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
> > @@ -3,7 +3,7 @@ include $(TOP)/configs/current
> >
> > EGL_DRIVER_NAME = swrast
> > EGL_DRIVER_SOURCES = dummy.c
> > -EGL_DRIVER_LIBS =
> > +EGL_DRIVER_LIBS = -lEGL
> >
> > EGL_DRIVER_PIPES = \
> > $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
> >
> > Then the eglInitialize() command still fails because of something else.
> >
> > When I run the application with the following settings:
> > EGL_DRIVER=egl_x11_swrast
> > EGL_SOFTWARE=1
> > EGL_DISPLAY=x11
> > EGL_LOG_LEVEL=debug
> >
> > I get:
> >
> > libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
> > libEGL info: use software fallback
> > libEGL warning: No supported client API
> > libEGL debug: no state tracker supports config 0x21
> > ... till ...
> > libEGL debug: no state tracker supports config 0x98
> > libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
> > add configs)
> > The demos in mesa/progs/egl give me the same output. While the demos
> > in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
> > wrong?
> >From which directory do you build your libGL? You need to use the one from
> src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
> Have a look at the OpenGL section in docs/egl.html.
>
|
|
From: Andreas P. <and...@gm...> - 2010-03-11 19:54:20
|
Hi, So far this seems to fix all build problems that I had. I will come back as soon as the build is complete. Will take some time .. My home system isnt the fasted. Thank you. regards Andreas 2010/3/11 Keith Whitwell <ke...@vm...>: > This may be related to the attached patch. Please let me know if this > improves things & I'll commit > > Keith > > [...] |
|
From: Andreas P. <and...@gm...> - 2010-03-11 20:59:24
|
Another build problem remained: make[5]: Entering directory `/home/mumiee/mesa/src/gallium/winsys/drm/swrast/egl' gcc -c -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o make[5]: *** No rule to make target `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by `egl_x11_swrast.so'. Stop. make[5]: Leaving directory `/home/mumiee/mesa/src/gallium/winsys/drm/swrast/egl' config.status contains: S["GALLIUM_WINSYS_DIRS"]=" drm" but i guess it should be S["GALLIUM_WINSYS_DIRS"]="xlib drm" i configured the build with ./configure --enable-egl --with-egl-displays=x11 --with-state-trackers=egl,vega,es --enable-gallium-swrast. 2010/3/11 Andreas Pokorny <and...@gm...>: > Hi, > So far this seems to fix all build problems that I had. I will come > back as soon as the build is complete. Will take some time .. My home > system isnt the fasted. > > Thank you. > > regards > Andreas > > 2010/3/11 Keith Whitwell <ke...@vm...>: >> This may be related to the attached patch. Please let me know if this >> improves things & I'll commit >> >> Keith >> >> [...] > |
|
From: Andreas P. <and...@gm...> - 2010-03-11 21:10:20
|
Hi, Another minor thing, make install yields: [...] /usr/bin/install -c -d /usr/local/lib/pkgconfig /bin/bash ../../bin/minstall ../../lib/libGL.*so* \ /usr/local/lib Unknown type of argument: ../../lib/libGL.*so* make[3]: *** [install-libgl] Error 1 make[3]: Leaving directory `/home/mumiee/mesa/src/mesa There is no libGL in lib/ I could not find the rule that tries to install libGL regards Andreas Pokorny |
|
From: Andreas P. <and...@gm...> - 2010-03-11 22:02:11
|
Hi,
2010/3/11 Chia-I Wu <ol...@gm...>:
> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
> <and...@gm...> wrote:
>> Hi,
>>
>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
>>
>> I have two rather strange problems using egl. I have implemented a
>> egl/es2/libX11 based renderer shared object file. The shared object
>> file gets loaded and initialized using dlopen/dlsym. Then when the
>> renderer is supposed to initialize EGL, and to create a window I run
>> into runtime symbol lookup errors.
>>
>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
>> undefined symbol: _eglInitDriverFallbacks
> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen
> who?). Do you have a sample code that reproduces your setup or the issue?
My applicatin dlopens a shared object files that links against EGL and
ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c
into a shared library. Then I dlopen the lib with
dlopen(RTLD_LAZY|RTLD_LOCAL); - and then i try to execute an exported
function of tri.c (turned main into a function with visibility
default) as it seems RTLD_LOCAL causes the issue. I have to use
RTLD_GLOBAL instead. So now it works.
I have no idea why i used RTLD_LOCAL in the first place.
>> When I add the following to the makefiles - it seems to work.
>>
>> --- a/src/gallium/winsys/drm/swrast/egl/Makefile
>> +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
>> @@ -3,7 +3,7 @@ include $(TOP)/configs/current
>>
>> EGL_DRIVER_NAME = swrast
>> EGL_DRIVER_SOURCES = dummy.c
>> -EGL_DRIVER_LIBS =
>> +EGL_DRIVER_LIBS = -lEGL
>>
>> EGL_DRIVER_PIPES = \
>> $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
>>
>> Then the eglInitialize() command still fails because of something else.
>>
>> When I run the application with the following settings:
>> EGL_DRIVER=egl_x11_swrast
>> EGL_SOFTWARE=1
>> EGL_DISPLAY=x11
>> EGL_LOG_LEVEL=debug
>>
>> I get:
>>
>> libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
>> libEGL info: use software fallback
>> libEGL warning: No supported client API
>> libEGL debug: no state tracker supports config 0x21
>> ... till ...
>> libEGL debug: no state tracker supports config 0x98
>> libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
>> add configs)
>> The demos in mesa/progs/egl give me the same output. While the demos
>> in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
>> wrong?
> From which directory do you build your libGL? You need to use the one from
> src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
> Have a look at the OpenGL section in docs/egl.html.
I did not build libGL, I was only interested in EGL and GLES1/ES2 and
VG. Do I have to build GL?
regards
Andreas Pokorny
|
|
From: Chia-I Wu <ol...@gm...> - 2010-03-12 03:09:50
|
On Fri, Mar 12, 2010 at 6:02 AM, Andreas Pokorny
<and...@gm...> wrote:
> 2010/3/11 Chia-I Wu <ol...@gm...>:
>> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny
>> <and...@gm...> wrote:
>>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee
>>> I have two rather strange problems using egl. I have implemented a
>>> egl/es2/libX11 based renderer shared object file. The shared object
>>> file gets loaded and initialized using dlopen/dlsym. Then when the
>>> renderer is supposed to initialize EGL, and to create a window I run
>>> into runtime symbol lookup errors.
>>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so:
>>> undefined symbol: _eglInitDriverFallbacks
>> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when
>> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen
>> who?). Do you have a sample code that reproduces your setup or the issue?
> My applicatin dlopens a shared object files that links against EGL and
> ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c
> into a shared library. Then I dlopen the lib with
> dlopen(RTLD_LAZY|RTLD_LOCAL); - and then i try to execute an exported
> function of tri.c (turned main into a function with visibility
> default) as it seems RTLD_LOCAL causes the issue. I have to use
> RTLD_GLOBAL instead. So now it works.
> I have no idea why i used RTLD_LOCAL in the first place.
Glad you solved your problem. dlopen()ing is one of the part in EGL that I
haven't looked at. I don't have enough experiences on various setups or Unixes
to say that EGL is doing the right thing.
>>> When I add the following to the makefiles - it seems to work.
>>>
>>> --- a/src/gallium/winsys/drm/swrast/egl/Makefile
>>> +++ b/src/gallium/winsys/drm/swrast/egl/Makefile
>>> @@ -3,7 +3,7 @@ include $(TOP)/configs/current
>>>
>>> EGL_DRIVER_NAME = swrast
>>> EGL_DRIVER_SOURCES = dummy.c
>>> -EGL_DRIVER_LIBS =
>>> +EGL_DRIVER_LIBS = -lEGL
>>>
>>> EGL_DRIVER_PIPES = \
>>> $(TOP)/src/gallium/winsys/drm/swrast/core/libswrastdrm.a \
>>>
>>> Then the eglInitialize() command still fails because of something else.
>>>
>>> When I run the application with the following settings:
>>> EGL_DRIVER=egl_x11_swrast
>>> EGL_SOFTWARE=1
>>> EGL_DISPLAY=x11
>>> EGL_LOG_LEVEL=debug
>>>
>>> I get:
>>>
>>> libEGL debug: dlopen(/usr/local/lib/egl/egl_x11_swrast.so)
>>> libEGL info: use software fallback
>>> libEGL warning: No supported client API
>>> libEGL debug: no state tracker supports config 0x21
>>> ... till ...
>>> libEGL debug: no state tracker supports config 0x98
>>> libEGL debug: EGL user error 0x3001 (other) in eglInitialize(unable to
>>> add configs)
>>> The demos in mesa/progs/egl give me the same output. While the demos
>>> in mesa/progs/{es2,es1}/xegl and work. Any ideas what I am doing
>>> wrong?
>> From which directory do you build your libGL? You need to use the one from
>> src/gallium/winsys/xlib (or src/gallium/targets/libgl-xlib/ in today's git).
>> Have a look at the OpenGL section in docs/egl.html.
> I did not build libGL, I was only interested in EGL and GLES1/ES2 and
> VG. Do I have to build GL?
No. Only if you want to run the demos under progs/egl/.
--
ol...@Lu...
|
|
From: Andreas P. <and...@gm...> - 2010-03-31 15:59:23
|
Hi, Its me again, 2010/3/12 Chia-I Wu <ol...@gm...>: > On Fri, Mar 12, 2010 at 6:02 AM, Andreas Pokorny > <and...@gm...> wrote: >> 2010/3/11 Chia-I Wu <ol...@gm...>: >>> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny >>> <and...@gm...> wrote: >>>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee >>>> I have two rather strange problems using egl. I have implemented a >>>> egl/es2/libX11 based renderer shared object file. The shared object >>>> file gets loaded and initialized using dlopen/dlsym. Then when the >>>> renderer is supposed to initialize EGL, and to create a window I run >>>> into runtime symbol lookup errors. >>>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so: >>>> undefined symbol: _eglInitDriverFallbacks >>> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when >>> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen >>> who?). Do you have a sample code that reproduces your setup or the issue? >> My applicatin dlopens a shared object files that links against EGL and >> ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c >> into a shared library. Then I dlopen the lib with >> dlopen(RTLD_LAZY|RTLD_LOCAL); - and then i try to execute an exported >> function of tri.c (turned main into a function with visibility >> default) as it seems RTLD_LOCAL causes the issue. I have to use >> RTLD_GLOBAL instead. So now it works. >> I have no idea why i used RTLD_LOCAL in the first place. > > Glad you solved your problem. dlopen()ing is one of the part in EGL that I > haven't looked at. I don't have enough experiences on various setups or Unixes > to say that EGL is doing the right thing. According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL causes a crash in a different es2/egl implementation. What is bad about explicitly linking to libEGL.so in the egl driver? >From my limited point of view it work without breaking anything. kind regards Andreas |
|
From: Chia-I Wu <ol...@gm...> - 2010-04-05 03:30:52
|
On Wed, Mar 31, 2010 at 05:59:16PM +0200, Andreas Pokorny wrote: > Its me again, > 2010/3/12 Chia-I Wu <ol...@gm...>: > > On Fri, Mar 12, 2010 at 6:02 AM, Andreas Pokorny > > <and...@gm...> wrote: > >> 2010/3/11 Chia-I Wu <ol...@gm...>: > >>> On Thu, Mar 11, 2010 at 10:06 PM, Andreas Pokorny > >>> <and...@gm...> wrote: > >>>> I work on: b8656c4825b9e054f05258773ba012e41d4fcdee > >>>> I have two rather strange problems using egl. I have implemented a > >>>> egl/es2/libX11 based renderer shared object file. The shared object > >>>> file gets loaded and initialized using dlopen/dlsym. Then when the > >>>> renderer is supposed to initialize EGL, and to create a window I run > >>>> into runtime symbol lookup errors. > >>>> ./Startup: symbol lookup error: /usr/local/lib/egl/egl_x11_swrast.so: > >>>> undefined symbol: _eglInitDriverFallbacks > >>> It seems _eglInitDriverFallbacks in libEGL.so is not resolved when > >>> egl_x11_swrast.so is loaded. I am not quite sure about your setup (who dlopen > >>> who?). Do you have a sample code that reproduces your setup or the issue? > >> My applicatin dlopens a shared object files that links against EGL and > >> ES2. I was just writing a sample code that turns progs/es2/xegl/tri.c > >> into a shared library. Then I dlopen the lib with > >> dlopen(RTLD_LAZY|RTLD_LOCAL); - and then i try to execute an exported > >> function of tri.c (turned main into a function with visibility > >> default) as it seems RTLD_LOCAL causes the issue. I have to use > >> RTLD_GLOBAL instead. So now it works. > >> I have no idea why i used RTLD_LOCAL in the first place. > > Glad you solved your problem. dlopen()ing is one of the part in EGL that I > > haven't looked at. I don't have enough experiences on various setups or Unixes > > to say that EGL is doing the right thing. > According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL > causes a crash in a different es2/egl implementation. > What is bad about explicitly linking to libEGL.so in the egl driver? > From my limited point of view it work without breaking anything. Sorry for the late response. Could the crash happen to be a version mismatch between libEGL and the driver? There is no version checking done right now.. As for linking back to libEGL, I was worried about cyclic linking. Currently, EGL drivers require back-linking to libEGL http://sourceware.org/autobook/autobook/autobook_172.html It is assumed to be a bad design. I hope to fix this intead of linking back to libEGL. -- ol...@Lu... |
|
From: Andreas P. <and...@gm...> - 2010-04-05 09:39:55
|
Hi, 2010/4/5 Chia-I Wu <ol...@gm...>: > On Wed, Mar 31, 2010 at 05:59:16PM +0200, Andreas Pokorny wrote: >> According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL >> causes a crash in a different es2/egl implementation. >> What is bad about explicitly linking to libEGL.so in the egl driver? >> From my limited point of view it work without breaking anything. > > Sorry for the late response. > > Could the crash happen to be a version mismatch between libEGL and the > driver? There is no version checking done right now.. The crash happens on an imx51 board equipped with a z430 of amd. The mesa stack is not involved. I am in contact with the vendor about this issue (more or less it is vacation time here). Even though I have a stack trace about the issue, I have no idea why it depends on the ld flags. Its just that at the moment a component that is rather unrelated to the actual rendering needs a build switch to either support loading a renderer module that either runs with this or the other implementation of libEGL. > As for linking back to libEGL, I was worried about cyclic linking. > Currently, EGL drivers require back-linking to libEGL > > http://sourceware.org/autobook/autobook/autobook_172.html > > It is assumed to be a bad design. I hope to fix this intead of linking > back to libEGL. So to make the graph directional again, one would have to strip libEGL from the support symbols, and provide then in a seperate library. Are these symbols provided by libEGL and used by the loaded modules required by all moduels, or is this only needed by swrast? regards Andreas |
|
From: Chia-I Wu <ol...@gm...> - 2010-04-06 04:45:31
|
On Mon, Apr 05, 2010 at 11:39:46AM +0200, Andreas Pokorny wrote: > 2010/4/5 Chia-I Wu <ol...@gm...>: > > On Wed, Mar 31, 2010 at 05:59:16PM +0200, Andreas Pokorny wrote: > >> According to git bisect the fix of chaning RTLD_LOCAL to RTLD_GLOBAL > >> causes a crash in a different es2/egl implementation. > >> What is bad about explicitly linking to libEGL.so in the egl driver? > >> From my limited point of view it work without breaking anything. > > Sorry for the late response. > > Could the crash happen to be a version mismatch between libEGL and the > > driver? There is no version checking done right now.. > The crash happens on an imx51 board equipped with a z430 of amd. The > mesa stack is not involved. I am in contact with the vendor about this > issue (more or less it is vacation time here). Even though I have a > stack trace about the issue, I have no idea why it depends on the ld > flags. Its just that at the moment a component that is rather > unrelated to the actual rendering needs a build switch to either > support loading a renderer module that either runs with this or the > other implementation of libEGL. > > As for linking back to libEGL, I was worried about cyclic linking. > > Currently, EGL drivers require back-linking to libEGL > > http://sourceware.org/autobook/autobook/autobook_172.html > > It is assumed to be a bad design. I hope to fix this intead of linking > > back to libEGL. > So to make the graph directional again, one would have to strip libEGL > from the support symbols, and provide then in a seperate library. Are > these symbols provided by libEGL and used by the loaded modules > required by all moduels, or is this only needed by swrast? They are needed by all EGL drivers. It might be as well to see how other projects with dynamic plugins deal with the back-linking. -- ol...@Lu... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X