Hello,
Does anyone have a list of packages which has dependency on OpenGL, OpenGLES, and/or EGL for Tizen 3.0:common?
Or, if you maintain such a package, could you let me know?
Off the top of my head, I could think of wayland-egl, gbm(?), wayland-drm, cairo/gles, evas/gles...
Thank you.
Best regards,
Sangwon Ha
------- Original Message -------
Sender : 하상원<[email protected]> S5(책임)/책임/차세대Computing Lab(S/W센터)/삼성전자
Date : 2014-07-30 19:57 (GMT+09:00)
Title : Re: [Dev] Building platform image with Mesa or Virtual driver in Tizen 3.0
I tried a few variations to get a better idea about .so, and the result of my experiment is that
the whole so versioning mechanism seems to "technically" work as long as there's an identical
.so file during run-time which matches the soname used during the compilation stage.
Anyway, the discussion seems to have drifted too much towards .so versioning issue, whereas,
my original intention was to have a more general topic on which is better for the long run,
opengl-es-virtual-drv? or Mesa?
Any suggestions?
------- Original Message -------
Sender : Yoon, Youngsik<[email protected]>
Date : 2014-07-28 16:49 (GMT+09:00)
Title : Re: [Dev] Building platform image with Mesa or Virtual driver in Tizen 3.0
> > Second is actually a question about whether it's possible or okay to
> > use unversioned .so during build time
I didn't try...but I think, in theory if you compiled your libXXX with this option "-soname=libXXX.so.N -o libXXX.so"
You can use unversioned .so at build time while it's still relying on .so.N at runtime.
But I don't see any merit in doing this.
Thanks,
Yoon
-----Original Message-----
From: Dev [mailto:[email protected]] On Behalf Of Patrick Ohly
Sent: Monday, July 28, 2014 3:45 PM
To: Carsten Haitzler
Cc: [email protected]
Subject: Re: [Dev] Building platform image with Mesa or Virtual driver in Tizen 3.0
On Sat, 2014-07-26 at 12:40 +0900, Carsten Haitzler wrote:
> > Second is actually a question about whether it's possible or okay to
> > use unversioned .so during build time
>
> no (assuming you mean only have a .so with no versions). the version
> (major) is determined by following the first .so link. you inlclude
> the .so link and it should point to .so.2 - that .so.2 is what your
> binary then relies on at runtime.
Minor technical nitpick: it is not the symlink names which somehow determine the actual runtime dependency. It is the SONAME inside the ELF file that gets found when opening the .so file name.
On my desktop system:
$ readelf -a /usr/lib/x86_64-linux-gnu/libGL.so | grep SONAME
0x000000000000000e (SONAME) Library soname: [libGL.so.1]
The linker really just looks for libGL.so and opens it, without checking what the symlink points to:
$ strace -f gcc -o /tmp/test /tmp/test.c -lGL 2>&1 | grep -e GL.so -e readlinkat [pid 4504] stat("/usr/lib/gcc/x86_64-linux-gnu/4.9/libGL.so", 0x7fff4d33cc90) = -1 ENOENT (No such file or directory) [pid 4504] open("/usr/lib/gcc/x86_64-linux-gnu/4.9/libGL.so", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4504] stat("/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libGL.so", {st_mode=S_IFREG|0644, st_size=422224, ...}) = 0 [pid 4504] open("/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libGL.so", O_RDONLY) = 8 [pid 4504] open("/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libGL.so", O_RDONLY) = 9
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
|
|
|
HA, SANGWON, Ph.D. SAMSUNG ELECTRONICS CO., LTD. TEL: +82-31-301-0057 |
|
|
|
HA, SANGWON, Ph.D. SAMSUNG ELECTRONICS CO., LTD. TEL: +82-31-301-0057 |
|
|
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
