[SOLVED]possible distro packaging issue related mesa. need confirm.

unixman · 2017-09-06 14:26:54

Hi. This is from freenode intel-3d channel log.Someone please confirm.

asdwsxcde	Hi dear devs. i get 'undefined symbol'.    do i have to use  eglgetprocaddress  for glMemoryBarrier when linking with GLESv2? Kabylake GPU and mesa-17.1.7 here.
my shader also print 'undefined symbol'  for memoryBarrier*  class shader built-in funcs.  version 320 es  specified in shader. Thanks.
i want to sure whether it is a bug or my own fault

15∶13 tpalli	asdwsxcde you should be able to just use it, it's part of the api, include gl32.h
asdwsxcde maybe for some reason you are not getting gles3.2, memoryBarrier() function(s) *should* be there
yvmarathe joined
thegreenhundred joined

15∶32tpalli	asdwsxcde also please verify that symbol is there, for example 'readelf -s --wide /usr/lib64/libGLESv2.so.2.0.0|grep MemoryBarrier' should give you something

15∶55 asdwsxcde	@tpalli: thank you.  No luck, command you mentioned print nothing.
sh-4.4$ readelf -s --wide /usr/lib/libGLESv2.so.2.0.0 | grep -i drawarrays
   196: 00000000000077e0     0 FUNC    GLOBAL DEFAULT   13 glDrawArraysInstanced
   201: 00000000000077c0     0 FUNC    GLOBAL DEFAULT   13 glDrawArrays
h-4.4$ readelf -s --wide /usr/lib/libGLESv2.so.2.0.0 | grep MemoryBarrier
sh-4.4$ 
maybe this is a distro bug
sh-4.4$ uname -a
Linux archlinux 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux
16∶05 i will ask this in distro forum

16∶16 Kayden	I wonder if that's actuall glvnd
*actually
the missing GLSL functions seems especially weird
not sure what would cause that
asdwsxcde	sh-4.4$ pacman -Qo /usr/lib/libGLESv2.so.2.0.0 
/usr/lib/libGLESv2.so.2.0.0 is owned by libglvnd 0.2.999+g4ba53457-2
sh-4.4$ 
So  yes

Last edited by unixman (2017-09-11 10:56:21)

Trilby · 2017-09-06 16:12:23

You're looking in the wrong so file. That symbol is in libGL and libOpenGL.

As for whatever your actual problem is, you might want to describe what you are trying to do: apparently you are trying to build something - what are you building, what is your compiler/linker command line, etc.

Please actually describe your problem, don't just dump some chat log and expect us to filter through it to try to figure out what you are asking.

Last edited by Trilby (2017-09-06 16:17:18)

unixman · 2017-09-07 09:34:26

Thanks for reply. Look below.

sh-4.4$ cat /usr/lib/pkgconfig/glesv2.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: glesv2
Description: Mesa OpenGL ES 2.0 library
Requires.private:
Version: 17.1.8
Libs: -L${libdir} -lGLESv2
Libs.private: -lm -lpthread -pthread -ldl
Cflags: -I${includedir}
sh-4.4$ 

sh-4.4$ grep glMemoryBarrier /usr/include/GLES3/gl32.h 
GL_APICALL void GL_APIENTRY glMemoryBarrier (GLbitfield barriers);
GL_APICALL void GL_APIENTRY glMemoryBarrierByRegion (GLbitfield barriers);
sh-4.4$

So output of below cmd should contains entries as intel dev says but NO.

sh-4.4$ readelf -s --wide /usr/lib/libGLESv2.so.2.0.0 | grep MemoryBarrier

You say arch provided libGLESv2.so contains no entries. How about other distros.(ubuntu, fedora etc)

i have not other distro installed, so i need help to sure whether this is mesa bug, distro bug or my own fault.

i discover this when building a trivial OpenGL ES 3.2 program linking with -lGLESv2.

it is print 'undefined symbol' just only for glMemoryBarrier when linking.

i can post the code if someone ask.

Trilby · 2017-09-07 11:22:52

I still don't see what your problem is. You showed a pkgconfig file for GLESv2, and checked the library for GLESv2 for a function and didn't find it. But that function is from GLES3! How about this:

 grep glMemoryBarrier /usr/include/GLES2/*

It returns nothing as that function is not in the GLES2 headers.

unixman wrote:

i discover this when building a trivial OpenGL ES 3.2 program linking with -lGLESv2.

(emphasis added) What do you expect to happen? You're linking to the wrong libs. You can't mix and match versions as you see fit and you should not be surprised if a newer version (which is backward compatible, but does introduce new features) does not have all of it's new features covered by the previous versions lib.

There doesn't seem to be a .pc file for gles3. I'm not sure if that's intentional. If there is supposed to be one, and that is your concern, then maybe that could be a packaging issue. But showing blocks of code where you are attempting to do things quite incorrectly and saying it doesn't work really isn't an indication of a packaging bug.

EDIT: Also note this from the mesa website:

mesa wrote:

Mesa implements OpenGL ES 1.1 and OpenGL ES 2.0.

So building v3 code against mesa may not be a good idea just yet.
EDIT2: It does seem the openGL libs (as I noted a couple posts above) *do* implement GLES3. But there does not seem to be a separate GLES3 lib.

Last edited by Trilby (2017-09-07 11:39:06)

unixman · 2017-09-11 08:43:30

Thank you. it is right that this is not distro issue but libglvnd.

I file a bug that it seems accepted and fixed. See below.

https://github.com/NVIDIA/libglvnd/issues/134

PS: Hey, i want this fix in my machine as soon as possible:)

Last edited by unixman (2017-09-11 08:47:54)

Arch Linux

#1 2017-09-06 14:26:54

[SOLVED]possible distro packaging issue related mesa. need confirm.

#2 2017-09-06 16:12:23

Re: [SOLVED]possible distro packaging issue related mesa. need confirm.

#3 2017-09-07 09:34:26

Re: [SOLVED]possible distro packaging issue related mesa. need confirm.

#4 2017-09-07 11:22:52

Re: [SOLVED]possible distro packaging issue related mesa. need confirm.

#5 2017-09-11 08:43:30

Re: [SOLVED]possible distro packaging issue related mesa. need confirm.

Board footer