=== trelane is now known as irker === irker is now known as trelane === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Quintasan_ is now known as Quintasan === doko_ is now known as doko [14:27] infinity, help ! === Quintasan_ is now known as Quintasan [15:20] ogra_: ? [15:20] infinity, i have a linker issue and wasted my whole day on it already :( [15:21] * ogra_ is super frustrated [15:21] squashfs? [15:21] nah [15:21] tegra driver [15:21] quantal-server-armhf+omap.squashfs [15:21] i just noticed it [15:21] 10 min update ... 6h hunting the linker [15:21] i feel sorry for you :) [15:22] infinity, so libGLESv2.so isnt versioned ... the package installes it to /usr/lib/nvidia-tegra and sets an ld.so.conf.d option ot use that path [15:22] during package build i create a proper symlink libGLESv2.so.2 [15:23] ogra_: well... you should just ditch your tegra... [15:23] using ldconfig in quantal i get libGLESv2.so -> libGLESv2.so.2 [15:23] ndec_: besides, any news on the omap5 panda side? [15:24] now running es2_info i get a lib not found error [15:24] ogra_: If it's not versioned, I'm not sure what you think the symlink will accomplish. [15:24] ogra_: If the ELF header doesn't have the versioned SONAME in it, you're fighting a losing battle there. [15:24] infinity, if i set LD_LIBRARY_PATH it works, if i copy the whole set of libs to /usr/lib or /lib ir works too [15:24] ppisati: any news? [15:25] and it worked with the same packaging in precise [15:25] it's coming soon. [15:25] infinity, so why do /usr/lib and /lib as well as setting the var just work then ? [15:25] (and why did it just work in precise as is) [15:27] ogra_: Dunno. Don't we use update-alternatives for GL/GLES in all the other packages? [15:27] i could make the package just install to /usr/lib indeed but i would like to know why that works if a subdir doesnt [15:27] infinity, we do ... doesnt help if ldconfig is so stict though [15:27] ogra_: And I can't say for sure why yours doesn't work without seeing the package. [15:27] apt-get source nvidia-tegra [15:27] (ldconfig hasn't changed at all since precise, so you're barking up the wrong blame tree there) [15:28] is there any way to get something readable out of objdump so that i can check what ldconfig actually sees ? [15:29] Hello All [15:29] janimo: Are you available& [15:29] ? [15:29] alex-ac100, yes [15:30] alex-ac100, I was just told by fly-away about the issue [15:30] Sorry for bother you, but just would like to let you know that last linux-meta-ac100 build is not correct [15:31] Ah OK, no issues === rickspencer3 is now known as rickspencer3-otp [15:32] janimo: I was not awaire that have to talk with you on THIS channel, looking for you on #ac100 since yesterday evening [15:32] ogra_, if you run ldd /usr/bin/es2_info do you get the paths that should be found? [15:33] alex-ac100, best use the mailing list I guess. I am not on #ac100. I mostly do a kernel update from time to time since noone else does it, but do not use the ac100 otherwise [15:33] janimo, yes, and ? [15:34] ogra_, are the libGLES ones missing? [15:34] janimo, its not about the app, its about the lib [15:34] the app asks ld and gets the wrong info ... unless the lib lives in /lib, /usr/lib or i gave the proper path with LD_LIBRARY_PATH [15:35] alex-ac100, ah wait the meta build? fly-away told me about NV_SOMETHING option needing turned off or hw accel does not work [15:35] is this a different issue? [15:35] in these three cases it works fine [15:35] ogra_, is the rel16 tarball putting the files in the same place as rel15? [15:35] yes [15:36] its exactly identical, just other binaries and a few changes to udev rules and the xorg.conf snippet [15:36] ogra_: What do you mean "not about the app, it's about the lib"? What does "ldd /usr/bin/es2_info" say? [15:37] janimo: looks like in kernel from linux-metaac100 has CONFIG_TEGRA_NVAVP=y in config. This is totally wrong, as this is for Tegra3 only, while ac100 is Tegra2 based [15:37] ogra_, I know the order of the lines ld.so scripts created/appended to by the postint mattered [15:37] I know I hated those parts of the package too [15:37] but I hoped they should all work from now on if we do not touch them anymore [15:38] janimo: For this reason video playback is broken with this kernel build [15:38] ogra_: do you know if the libs are providing a valid SONAME? [15:38] alex-ac100, right. So you mean the new kernel package not the meta? [15:38] the latter just says which is the actual kernel image deb and does not have any config settings [15:38] rsalveti, how do i find out ? [15:39] janimo: I mean this one https://lists.ubuntu.com/archives/quantal-changes/2012-September/010128.html [15:39] rsalveti, i definitely see the wrong name being used in ldconfig [15:39] rsalveti, but that didnt change vs precise ... thats my issue [15:39] ogra_: objdump -x lib | grep SONAME [15:39] alex-ac100, ok, the config issue. I was just confused by you mentioning meta (the namings are confusing for newcomers too so no problem) [15:39] the lib is the same way broken as in the former version [15:40] ogra_: were you using update alternatives at the previous version? [15:40] yes [15:40] its the same package, i only replaced the binary blobs [15:40] janimo: Sorry, I'm not familar with terminology, so my mistake [15:40] alex-ac100, yes, no prob, as I said confusing package names :) [15:41] ogra_: by default the gl applications will look for the .so.xx libs, but I suppose you already got the links in place, right? [15:41] rsalveti, yep [15:41] just because I saw a few gles libs just providing the .so one in the past [15:41] and that caused run time issues [15:41] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ objdump -x usr/lib/libGLESv2.so |grep SONAME [15:41] SONAME libGLESv2.so [15:41] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0 [15:42] the problem with the lack of sonames is more if you decide to build something with it [15:42] yup, no version there [15:42] wait [15:42] gets better [15:42] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ objdump -x usr/lib/libGLESv2.so |grep SONAME [15:42] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ [15:42] The lack of proper SOVER will confuse the crap out of ld.so [15:42] infinity: even at runtime? [15:42] so apparently ld works fine if there is no SONAME at all [15:43] rsalveti: Yes, cause ld won't map the symbols correctly. [15:43] hm, it might be the case that having SONAME but without version might be causing issues there [15:43] ye, it does [15:43] but why is just the link used if there is no SONAME ? [15:44] the lib lives in the same taret place in both packages [15:44] *target [15:44] with the same linakge [15:44] infinity: could be, but I believe it'd probably work in this case [15:44] *linkage [15:44] the libs are supposed to be fully compatible :-) [15:45] ogra_: ldconfig sets up links based on SOVER. [15:45] also why does it work in /usr/lib ? [15:45] ogra_: Working in /usr/lib is probably a red herring, but let me look at this in a bit. [15:46] ogra_: at the pvr-omap4 one I also had to remove the rpath from the libs [15:46] to get it to work properly [15:46] Oh, if it has an RPATH, that would explain the /usr/lib thing. [15:46] well, i think i would break the license if i touched the binary [15:47] ogra_: can you list the rpath available at your library? [15:47] not necessarily [15:48] ogra_: chrpath -l lib.so [15:48] I think at the pvr-omap4 case it had /usr/lib in it [15:49] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so [15:49] `usr/lib/libGLESv2.so' probably isn't a 64-bit LSB-first ELF file. [15:49] elf_open: Exec format error [15:49] (And yes, that probably violates the letter of the license to change/remove the rpath but, hey, I used to hex edit GL libraries in linux-restricted-modules) :P [15:49] GRRR [15:49] one sec [15:49] alex-ac100, btw are you sure this is for tegra3 only? The kernel config system should not allow it to be set in that case [15:50] ogra_: please try 'find usr/lib -maxdepth 1 -iname "*.so*" -type f -exec chrpath -d {} +' [15:50] and see if it works better [15:50] infinity: well, we're just removing stuff from the library :P [15:50] not adding anything hehe [15:50] ogra@sabre:~/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so [15:50] usr/lib/libGLESv2.so: no rpath or runpath tag found. [15:51] ogra_: for all libs? [15:51] check the libEGL one [15:52] rsalveti: Removing things is still altering them (but yes, I don't much care either, and back when I used to hex edit the bejesus out of nvidia and ATI's libGL, both upstreams told me they didn't care) [15:52] That said, the nvidia upstream for the x86 drivers is a completely different group than for the ARM ones. [15:52] For reasons I'll never understand. [15:53] rsalveti, yes, for all libs [15:53] infinity: hehe, true [15:53] so now the 1mio $ question ... is there a way ro wipe the SONAME ? [15:53] *to [15:54] the interesting thing is that it's working on the /usr/lib and /lib paths [15:54] right [15:54] janimo: well not 100%, but when this nvavp option is activated, kernel tried to looad some firmware file [15:54] load [15:54] ogra_: I think there might be a way to wipe it out [15:54] alex-ac100, then maybe we just need to package that firmware file too? [15:54] it should be fwiw [15:54] This firmware is not include in R16 package [15:55] alex-ac100, at least this does not sound scary from the description: [15:55] http://paste.ubuntu.com/1254125/ [15:55] janimo: and this firmware in not necessary [15:55] alex-ac100, that will likely be in the codecs package [15:55] ogra_, should we package those too? [15:55] ogra_: what is the issue specifically, you're not able to find it at runtime? [15:55] janimo, i would like to :) [15:55] put them in linux-firmware? [15:55] ogra_: even when forcing the ld path? [15:55] rsalveti, right [15:56] janimo: ogra_ no, I tested with some custome kernel build without this config settings [15:56] as said above it works with LD:LIBRARY_PATH (which likely just overrides ld here and uses the links) [15:56] Hardware Video playback worked fine on that build [15:56] k [15:56] WITHOUT that file [15:57] Also one guy tried to provide such firmware file, it was included in some nvidia codec pack, not sure which platform. System hanged after loadin it [15:58] loading [15:59] janimo, marvin removed nvavp from paz00_defconfig (https://gitorious.org/~marvin24/ac100/marvin24s-kernel/commit/925a5b3d7ab784fc50b4d1edc4a78fa064e7eb0e). nvavp doesn't work for us (checked on android and linux). [15:59] stuw, ok I will remove it from the next upload [16:00] janimo, thx [16:00] ogra_: I'm stuck tethering this morning, but I'm downloading things as fast as I can to have a quick poke around. :P [16:00] infinity, i'll push the r16 package somewhere too for comparison [16:01] ogra_: Oh, yes, please do. [16:01] * ogra_ wants a chsoname tool :P [16:02] That may not be the issue. Especially if, as you claim, it works with different paths. [16:02] But I want to look at it all first. [16:02] (Well, it may not be the only issue... It *is* an issue that the library has a broken SONAME, but...) [16:02] well, the former oversion doesnt have a SONAME at all and works :) [16:03] ogra_: did you try running with LD_DEBUG to see if that would help? [16:03] ah, no, not yet [16:04] what should i run that way ? ldconfig or es2_info [16:04] es2_info [16:04] k [16:05] LD_DEBUG=files [16:05] LD_DEBUG=init [16:05] and others as well [16:06] I still kinda want to know what the output of ldd is/was. [16:07] But meh. Give me packages, and I can debug myself. [16:07] infinity, http://people.canonical.com/~ogra/tegra/nvidia-graphics-drivers-tegra* [16:08] so with ÖD_LIBRARY_PATH set i see direct_opencount=1 for libGLES [16:08] without the var set it properly tells me it cant find the lib [16:08] Can't find the lib is a bit odd, since mesa installs one. [16:08] So, something's gone horribly wrong. [16:09] Also, installing the 15.1.0-0ubuntu1 version in my chroot just failed... [16:09] err, no, we have overriden the mesa install path from ld with an alternative [16:10] update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory [16:10] update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory [16:10] Brilliant. [16:10] Also, double-paste. Bleh. [16:10] http://paste.ubuntu.com/1254162/ http://paste.ubuntu.com/1254166/ [16:10] first is without, second with LD_LIBRARY_PATH set [16:11] (ldd output) [16:11] ogra_: So, uhm. This package is missing a dependency... [16:11] infinity, werid, no idea wheer that comes from [16:11] oh ? [16:12] ogra_: Likely on xorg-video-abi-13. [16:12] the r16 package has it [16:12] 15 didnt, right [16:12] Ahh, kay. So, fixed in future. :P [16:12] yeah :) [16:12] Let me install an xserver and try again. [16:12] precise didnt complain about that ... [16:12] (lintian didnt) [16:13] iirc now it does [16:13] No, but installing in a bare chroot sure complains. [16:13] (See above) [16:13] yeah [16:14] Oh, still broken. [16:14] Your package should probably also ship the /usr/lib/xorg/modules/drivers/ directory... [16:15] Otherwise, the postinst only works if one has other X drivers installed. :P [16:15] Which is a bit silly. [16:15] btw http://paste.ubuntu.com/1254177/ [16:16] ldd with the lib in /usr/lib [16:16] infinity, hmm, the tarball does, weird i thought the package would just use that ... i'll add it to .dirs [16:17] ogra_: Also, while I'm nitpicking, arm-linux-gnueabi_EGL.conf should be gnueabihf_EGL [16:17] infinity, r16 ;) [16:17] already fixed [16:17] That could be where your problem lies. [16:17] no, i'm installin on a virgin ac100 [16:18] Since eabihf_EGL is an alternative shared by mesa. [16:18] The other one wasn't. [16:18] eabi_EGL was until precise [16:18] but only on armel :) [16:18] for which we dont build [16:18] (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# ls [16:18] arm-linux-gnueabi_EGL.conf arm-linux-gnueabihf.conf arm-linux-gnueabihf_EGL.conf libc.conf [16:18] Yes, well. [16:19] My point is that in the above scenario, we get arm-linux-gnueabi_EGL.conf parsed first (which has what you want in it). [16:19] Once you set up the correct alternatives, it may be doing something you didn't expect. [16:19] right, but that file is gone in r16 [16:19] But I'll find out once I build your binaries. [16:19] ogra_: I know the file should be gone in r16, I'm saying that might be your problem. :P [16:19] oh. i can push my binary for you as well ... [16:20] ogra_: Too late, sbuild's finished installing build-deps. :P [16:20] I assume the build itself is a few seconds. [16:20] yep [16:20] pretty niosy about the symbols :) [16:21] just for completion, there is no arm-linux-gnueabi_* file in my /etc/ld.so.conf.d (and never was on this install) [16:22] (helps to have three ac100's :) ) [16:25] marvin24, ohhh, intrestin, with the plain kernel video driver i always need to switch to console and back after DPMS, using the tegra driver it just wakes up fine [16:26] * ogra_ glares at http://paste.ubuntu.com/1254177/ [16:27] intresting that it loads all the other libs from /usr/lib/nvidia-tegra ... just not EGL and GLES [16:29] ogra_: yes, wake up works better with tegra drivers [16:32] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ for file in $(ls usr/lib/*.so);do objdump -x $file|grep SONAME;done|grep .so |wc -l [16:32] objdump: usr/lib/libnvrm_impl.so: File format not recognized [16:32] 0 [16:33] ... [16:33] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ for file in $(ls usr/lib/*.so);do objdump -x $file|grep SONAME;done|grep .so |wc -l [16:33] 57 [16:33] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ [16:33] so it seems nvidia tried to be nice and added SONAMEs all over the place ... [16:33] just that they didnt add any versioning ... [16:33] ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ for file in $(ls usr/lib/*.so);do objdump -x $file|grep SONAME;done|grep .so. |wc -l [16:33] 0 [16:39] * ogra_ thinks he should just install libEGL.so and libGLESv2.so (and their links) to /usr/bin and be done [16:39] or link them there or so [16:40] the mesa ones wont be used because we override the alternative [16:41] infinity, ^^^ do you think that could cause any havoc ? [16:43] * ogra_ goes to find some coffee [16:43] ogra_: would probably cause issues with any gles software you might build there [16:43] remember that once you built with a wrong SONAME, things get messy [16:44] i would be fine with that and a release note for ac100 ... and the possibility that nvidia fixes it in 3 months or so to SRU it [16:44] it wont make the release if i dont get it in somehow [16:45] and that would be a shame ... took 2 years to get nvidia to a point where they are on the same ABI and have a working driver released in time for us [16:45] rsalveti, also wouldnt builds use mesa anyway ? [16:46] ogra_: Uhm, your alternatives still seem broken here. [16:46] infinity, in what way ? [16:46] ogra_: In that I still have a arm-linux-gnueabi_EGL.conf with the r16 package. [16:47] the broken soname would affect us even with the right and multi-arch compatible path [16:47] http://paste.ubuntu.com/1254227/ [16:47] thats how it looks for me [16:47] so I don't think there's any easy way out here [16:47] did you uninstall r15 ? [16:47] ogra_: I just built and installed from your sources. [16:48] we should probably just try to get this working with multi-arch and update-alternatives and get it to the archive [16:48] rsalveti, but how without hacking the SONAME ? [16:48] we first need to understand if that's really the issue [16:48] we currently don't know what is happening :-) [16:49] well, its the obvious difference between r15 and r16 [16:49] (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# update-alternatives --list arm-linux-gnueabihf_egl_conf [16:49] /usr/lib/arm-linux-gnueabihf/mesa-egl/ld.so.conf [16:49] r15 no SONAME, apps follow the links ... r16 SONAME but wrong, ldconfig caches the wrong soname, apps fall over because the wrong SONAME is provided [16:50] Before we faff about SONAMEs, let's address this business. :P [16:50] ogra_: Are your local sources different from the ones you pointed me at? [16:50] just checking that [16:51] --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/nvidia-tegra/ld.so.conf 9000 [16:51] thats in my current postinst [16:52] Yeah, that's not what I have here. [16:52] ah, super sorry [16:52] Also, your prerm will need to both remove the old and new ones, but maybe it does in your version. [16:52] not yet, but i'm aware [16:53] Let me do this by hand and see where it lands me. [16:55] Alright, that gets me to your breakage now. [16:57] Hrm. [16:57] ln -s /usr/lib/nvidia-tegra/libGLESv2.so.2 /usr/lib/ [16:57] ^-- That really shouldn't work. [16:57] But it does. Grr. [16:58] And LD_DEBUG=all just shows that it's not using /usr/lib/nvidia-tegra in the search path at all. [16:59] So, not necessarily the SONAME to blame here. [17:00] werid, because ldconfig -v just lists the libs fine [17:01] i get: libGLESv2.so -> libGLESv2.so.2 [17:01] (note the wrong order due to the SONAME) [17:01] I don't... [17:01] I don't get it listed at all. [17:01] Or, I can't type. [17:01] well, i do, probably your alternatives are still wonky ? [17:02] The thing is, linking it in /lib doesn't change the wonkiness of that so -> so.2 thing. [17:02] It just starts showing up in searched. [17:02] with LD_DEBUG i see that libGLESv2.so.2 gets directly loaded when in /usr/lib [17:02] seaches* [17:02] right [17:03] it will make binaries work :) [17:03] Yeah, but. That doesn't tell me anything about what's wrong. [17:05] * infinity compares a chroot with r15 to one with r16 to sort this out. [17:05] nothin is worng (apart probably from being able to force loading of a lib if i put it in /usr/lib) [17:05] ld does the right thing [17:05] Which right thing is that? [17:05] using the SONAME and caching the lib info with it [17:06] its not ld's fault that the SONAME has no version number [17:06] Well, yes, that's the right thing, but that shouldn't relate to search paths. [17:06] oh, still taht [17:06] sorry, thought you solved that bit yet [17:07] No, if it was searching the path, it would work. [17:07] That's how it finds it when it's in /lib [17:08] oh, inbtresting ... ldconfig -v with the lib in both places shows me the SONAME issue for both even [17:08] ogra_: Yeah, I said that earlier. [17:08] ah [17:14] Okay, so looks like two bugs. [17:14] One is the library having the wrong SONAME, which means it won't land in the cache. [17:14] right [17:15] The other is that ld.so doesn't search the extended path, only ldconfig. [17:15] oh [17:15] and that changed since precise ? [17:15] So, ldconfig will search the path and add "correct" libraries to the cache. But our library is broken, so it doesn't get cached. [17:15] Later, ld.so searches the cache, finds nothing, and then walks the built-in directories it knows about. [17:15] No, it didn't change. [17:15] The r15 library gets cached. [17:16] And found from the cache. [17:16] So no walking required. [17:16] it doesnt have a SONAME [17:16] Yes, which is apparently better than having an incorrect one. :P [17:16] lol [17:16] yeah [17:16] obviously [17:16] so do you know any trick to wipe the SONAME field (or ven fix it) [17:17] *even [17:17] If there's padding in the ELF header, you could fix it. [17:17] Check with a hex editor. [17:20] padding would be zeros ? [17:21] Yeah. [17:21] hexedit doesnt really show anything usable on the right ... [17:21] and there seem to be no zeros at the start of the file [17:23] GCC: (crosstool-NG hg_unknown@20110628.165246) 4.5.3 [17:23] heh [17:23] 4.5 [17:24] Boom, easily fixed. [17:25] ?? [17:25] There's a bunch of nulls after GLIBC_2.4 [17:25] yep, i see them [17:25] e_match.__cxa_call_unexpected.libGLESv2.so.GLIBC_2.4................ [17:25] So, you replace libGLESv2.so\0GLIBC_2.4\0\0 with libGLESv2.so.2\0GLIBC_2.4 [17:25] And it all magically works. [17:26] The same needs to be done for libEGL.so.1 as well. And who knows what else. [17:26] A quick binary patching script to fix it up in the build wouldn't be much effort. [17:26] only the two to make binaries work at least [17:26] And would be the more "correct" fix anyway. [17:26] As annoying as it is. [17:27] >/me has never done somethin like this, do you know odf an example ? [17:29] (i manage editing with hexedit indeed, but have no idea how i would have to script that) [17:31] sed -i -e 's/libEGL.so\x00GLIBC_2.4\x00\x00/libEGL.so.1\x00GLIBC_2.4/' /usr/lib/nvidia-tegra/libEGL.so [17:31] you can sed that ?!?!?! [17:31] geez [17:31] ^-- That seemed to DTRT for my libEGL, cook as appropriate for others. [17:32] ogra_: Requires GNU sed (\x00 is a GNU extention), but we don't ship any other POSIX seds anyway, so whatever. [17:32] * ogra_ wouldnt have thought of sed ... probably some dd and cat weirdnesses, but not sed :) [17:33] Hrm, that might not have worked actually. sed may have broken it. [17:33] Was good enough for ldconfig, not good enough for ld.so. :P [17:33] (While hand-editing was good enough for both...) [17:33] There was a nice C-based binary patches in LRM, back when LRM still existed. [17:33] yeah, i'm still poking bytes here [17:33] I can try to dig it up in a bit. [17:34] Oh wait. Hahaha. [17:34] No, it's not that sed broke it. [17:34] well, worst case i change it while repackaging the updatream tarball [17:34] *upstream [17:34] It's that other libraries are linked to libEGL.so, which doesn't exist once I've done that. [17:34] i have to do that anyway to match the format of the package [17:35] So braindead. [17:35] oh, indeed, all libs use the broken sonames :) [17:36] * infinity head -> desk. [17:36] So, monkey-patching the SONAMEs won't work, since while that fixes all OUR binaries, it breaks all of THEIRS. [17:36] Brilliant. [17:36] btw, is there any particular reason that ld doesnt search additional dirs ? [17:37] Other than it being painfully slow to make ld.so parse a conf.d directory for run-time configs, no. [17:37] It's meant to trust the cache. [17:37] k [17:37] Which would work, if the cache was caching libraries that weren't insane. [17:37] heh [17:39] Do you have a good enough rapport with upstream to just get them to fix their SONAMEs? [17:39] Cause this is going to end up on our end with either a mess of incorrect symlinks, or monkeypatching and a few incorrect symlinks. [17:39] Neither is pretty. [17:39] not in time [17:39] And neither is correct. [17:40] Cause you're going to have to ship "dev" symlinks (/usr/lib/*.so) to make this work, even after patching the binaries to be unbroken. [17:40] Well, maybe you could patch the NEEDED section in everything too... [17:40] well, as i said in the beginning, i would just install EGL and GLES to /usr/lib [17:41] Yeah, or that. Still broken. :/ [17:41] all others arent versioned at all and are only used by these two [17:41]