Ok!
The dlopen error has been resolved by recompiling targeting
opengl-es/egl, but I'm gettting another error now:
ESTART: 2.10681 [0.00085] - Compositor Init
Enlightenment cannot initialize X Connection...
LOAD WL_WL MODULE
Could not create wayland canvas
LOAD WL_X11 MODULE
X11 connect failed!
LOAD WL_DRM MODULE
ERR<26151>:ecore_drm2 ../src/lib/ecore_drm2/ecore_drm2_device.c:602
ecore_drm2_device_open() Could not connect to input manager
ERR<26151>:ecore_evas
../src/modules/ecore_evas/engines/drm/ecore_evas_drm.c:164
_ecore_evas_drm_init() Failed to open device
ERR<26151>:ecore_drm2 ../src/lib/ecore_drm2/ecore_drm2_device.c:602
ecore_drm2_device_open() Could not connect to input manager
ERR<26151>:ecore_evas
../src/modules/ecore_evas/engines/drm/ecore_evas_drm.c:164
_ecore_evas_drm_init() Failed to open device
Could not create ecore_evas_drm canvas<<<< Enlightenment Error >>>>
Enlightenment cannot create a compositor.
E: Begin Shutdown Procedure!
ERR<26151>:e ../src/bin/e_msgbus.c:84 _e_msgbus_request_name_cb() Could
not request bus name
Looks like I'm missing my "input manager", would that be the dependent
xkbcommon package?
On 9/24/19 5:03 PM, Carsten Haitzler wrote:
On Tue, 24 Sep 2019 14:03:55 -0500 Matthew Kolar <mjko...@charter.net> said:
Raster,
Ah! That would probably be it, I just went with the default full-opengl,
I will have to download new git in that case, if it's going to be
default. I presume that this goes for both efl and E, and that I wont
have to specify gl-es on either anymore?
e doesn't know or care about full opengl vs egl/gles - ti deals with efl as the
abstraction and efl abstracts this generally at a high level or exposes a gles
api from evas_gl regardless what back-end evas was built for.
Matthew
On 9/24/19 12:27 PM, Carsten Haitzler (The Rasterman) wrote:
On Tue, 24 Sep 2019 11:47:43 -0500 Matthew Kolar <mjko...@charter.net> said:
this:
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f1e2d0c0000)
did you not enable gles. full opengl is not supported other than in x11 (and
osx)? i actually just switched the default to gl-es because people keep
forgetting to switch to gles to have wl/drm work.
Raster,
Here is some relevant console output:
bash-5.0$ ldd /usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so
linux-vdso.so.1 (0x00007fffd23fe000)
libeina.so.1 => /usr/lib64/libeina.so.1 (0x00007f1e2d4c0000)
libevas.so.1 => /usr/lib64/libevas.so.1 (0x00007f1e2d1f1000)
libecore.so.1 => /usr/lib64/libecore.so.1 (0x00007f1e2d172000)
libecore_drm2.so.1 => /usr/lib64/libecore_drm2.so.1
(0x00007f1e2d15e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1e2d159000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f1e2d0c0000)
libgbm.so.1 => /usr/lib64/libgbm.so.1 (0x00007f1e2d0ae000)
libwayland-client.so.0 => /usr/lib64/libwayland-client.so.0
(0x00007f1e2d09e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1e2ceb9000)
libm.so.6 => /lib64/libm.so.6 (0x00007f1e2cd6e000)
librt.so.1 => /lib64/librt.so.1 (0x00007f1e2cd64000)
libunwind-x86_64.so.8 => /usr/lib64/libunwind-x86_64.so.8
(0x00007f1e2cd45000)
libunwind.so.8 => /usr/lib64/libunwind.so.8 (0x00007f1e2cd29000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1e2cd08000)
libeo.so.1 => /usr/lib64/libeo.so.1 (0x00007f1e2cce3000)
libector.so.1 => /usr/lib64/libector.so.1 (0x00007f1e2cca5000)
libefl.so.1 => /usr/lib64/libefl.so.1 (0x00007f1e2cc2f000)
libemile.so.1 => /usr/lib64/libemile.so.1 (0x00007f1e2cbf4000)
libeet.so.1 => /usr/lib64/libeet.so.1 (0x00007f1e2cbbf000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6
(0x00007f1e2cb03000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1
(0x00007f1e2cabd000)
libfribidi.so.0 => /usr/lib64/libfribidi.so.0
(0x00007f1e2ca9f000) libluajit-5.1.so.2 => /usr/lib64/libluajit-5.1.so.2
(0x00007f1e2ca2d000)
libharfbuzz.so.0 => /usr/lib64/libharfbuzz.so.0
(0x00007f1e2c941000)
libgif.so.7 => /usr/lib64/libgif.so.7 (0x00007f1e2c932000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f1e2c89d000)
libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f1e2c868000)
libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007f1e2c7eb000)
libwebp.so.7 => /usr/lib64/libwebp.so.7 (0x00007f1e2c77d000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
(0x00007f1e2c65c000)
libeeze.so.1 => /usr/lib64/libeeze.so.1 (0x00007f1e2c647000)
libelput.so.1 => /usr/lib64/libelput.so.1 (0x00007f1e2c636000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e2d5a6000)
libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f1e2c603000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f1e2c4c5000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f1e2c4b1000)
libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0
(0x00007f1e2c3f5000)
libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f1e2c3e0000)
libwayland-server.so.0 => /usr/lib64/libwayland-server.so.0
(0x00007f1e2c3ca000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f1e2c39d000)
libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f1e2c195000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f1e2c17b000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f1e2bf55000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f1e2bebe000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f1e2bbde000)
libz.so.1 => /lib64/libz.so.1 (0x00007f1e2b9c7000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f1e2b9b4000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f1e2b9ab000)
libgraphite2.so.3 => /usr/lib64/libgraphite2.so.3
(0x00007f1e2b982000)
libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x00007f1e2b8db000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f1e2b868000)
libecore_file.so.1 => /usr/lib64/libecore_file.so.1
(0x00007f1e2b85e000)
libmount.so.1 => /lib64/libmount.so.1 (0x00007f1e2b800000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f1e2b7da000)
libeldbus.so.1 => /usr/lib64/libeldbus.so.1 (0x00007f1e2b798000)
libecore_input.so.1 => /usr/lib64/libecore_input.so.1
(0x00007f1e2b781000)
libinput.so.10 => /usr/lib64/libinput.so.10 (0x00007f1e2b739000)
libxkbcommon.so.0 => /usr/lib64/libxkbcommon.so.0
(0x00007f1e2b6f9000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f1e2b6d0000)
libecore_con.so.1 => /usr/lib64/libecore_con.so.1
(0x00007f1e2b62e000)
libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f1e2b5db000)
libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f1e2b588000)
libmtdev.so.1 => /usr/lib64/libmtdev.so.1 (0x00007f1e2b382000)
libevdev.so.2 => /usr/lib64/libevdev.so.2 (0x00007f1e2b365000)
libwacom.so.2 => /usr/lib64/libwacom.so.2 (0x00007f1e2b359000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f1e2b352000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f1e2b34a000)
libgudev-1.0.so.0 => /lib64/libgudev-1.0.so.0
(0x00007f1e2b33d000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0
(0x00007f1e2b2e2000)
libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0
(0x00007f1e2b128000) libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0
(0x00007f1e2b120000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f1e2b105000)
bash-5.0$ ldd /usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so |
grep 'EGL'
bash-5.0$ ldd /usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so |
grep 'libEGL'
EGL/libEGL doesnt seem to appear in the list at all. I know I set the
compile options up for this, so what gives?
Matthew
On 9/24/19 10:19 AM, Carsten Haitzler (The Rasterman) wrote:
On Mon, 23 Sep 2019 23:17:25 -0500 Matthew Kolar <mjko...@charter.net>
said:
Ok,
After doing some checking myself, it looks like a mesa bit, so I'm going
to post a link to my slackbuild with the meson options I compiled mesa
with.
https://pastebin.com/y4PJjyqx
The only thing I can see that would cause things to go amiss is "
-Dgles1=false " But I'm skeptical, as "-Dgles2=true" is enabled, I think
that should take care of it.
Brokenshakles
the build script for mesa isn't going to help much as it doesn't tell me
about the state of your system. what is installed where?
dlopen("/usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so",
/usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so: undefined
symbol: eglGetConfigs): RTLD_NOW
that is your core issue. have you run ldd on that module.so to see what it
links to? it should have linked to libEGL ... compilation should have
failed to begin with if that didn't happen.so ldd should tell you WHICH
libEGL is being found at runtime. maybe you have multipe libEGL's? that
would be a big problem source to begin with.
the EGL api definition/interface defines that it needs eglGetConfigs - if
it's not there then your libEGL is broken. that symbol doesn't exist.
https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglGetConfigs.xhtml
you can start dissecting whatever libEGL's you may have and look at
symbols (ldd, then nm) and so on and find out what is going on, but the
simple version is:
"your system is broken" or appears to be as the output does not say it
can't find libEGL ... it can seemingly find it... what it finds is
broken. follow the breadcrumbs. :)
On 9/23/19 11:05 PM, Matthew Kolar wrote:
Raster,
Ok, so what is the offending package? wayland-egl or mesa?
Brokenshakles
On 9/23/19 6:52 PM, Carsten Haitzler (The Rasterman) wrote:
On Mon, 23 Sep 2019 10:30:01 -0500 Matthew Kolar
<mjko...@charter.net> said:
did you pass E_WL_FORCE=1 s an env var? don't do that. tbat's not
needed at
all. don't set that. it's meant to be used to force a specific
rendering engine. just don't pass that env var and it should be
better. that's what the
wl_1 issue is. you have other issues like:
/usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so: undefined
symbol: eglGetConfigs): RTLD_NOW
the gl engine has linked to an egl but your system libEGL is missing
that symbol
- your system is somehow broken.
Hello everyone, if you have been on IRC recently, you know that I have
been trying to get E-Wayland running on Slackware64. So far, things
have been going well, most everything is compiled, but when I try to
run
wayland via enlightenment_start, I get the following:
MODULE ERR: [Error loading Module]
There was an error loading the module named: wl_1<ps/>No module named
wl_1/linux-gnu-x86_64-0.23.0/module.so could be found in
the<ps/>module search directories.<ps/>
Enlightenment cannot initialize X Connection...
LOAD WL_WL MODULE
ERR<14049>:eina_safety ../src/lib/ecore_evas/ecore_evas.c:4484
ecore_evas_wayland_egl_new() safety check failed: new == NULL
Could not create wayland canvas
LOAD WL_X11 MODULE
X11 connect failed!
LOAD WL_DRM MODULE
ERR<14049>:eina_module ../src/lib/eina/eina_module.c:327
eina_module_load() could not
dlopen("/usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so",
/usr/lib64/evas/modules/engines/gl_drm/v-1.23/module.so: undefined
symbol: eglGetConfigs): RTLD_NOW
ERR<14049>:ecore_drm2 ../src/lib/ecore_drm2/ecore_drm2_device.c:602
ecore_drm2_device_open() Could not connect to input manager
ERR<14049>:ecore_evas
../src/modules/ecore_evas/engines/drm/ecore_evas_drm.c:164
_ecore_evas_drm_init() Failed to open device
Could not create ecore_evas_drm canvas<<<< Enlightenment Error >>>>
Enlightenment cannot create a compositor.
It looks like dlopen is having symbol issues. Now I know I compiled
in egl support into efl and mesa, and that the stated module exists so
anyone have any clue to why it's not finding eglGetConfigs ?
Brokenshakles
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
