**** BEGIN LOGGING AT Mon Oct 01 03:00:00 2012 Oct 01 14:27:14 infinity, help ! Oct 01 15:20:39 ogra_: ? Oct 01 15:20:59 infinity, i have a linker issue and wasted my whole day on it already :( Oct 01 15:21:07 * ogra_ is super frustrated Oct 01 15:21:13 squashfs? Oct 01 15:21:19 nah Oct 01 15:21:22 tegra driver Oct 01 15:21:25 quantal-server-armhf+omap.squashfs Oct 01 15:21:35 i just noticed it Oct 01 15:21:43 10 min update ... 6h hunting the linker Oct 01 15:21:57 i feel sorry for you :) Oct 01 15:22:33 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 Oct 01 15:22:59 during package build i create a proper symlink libGLESv2.so.2 Oct 01 15:23:14 ogra_: well... you should just ditch your tegra... Oct 01 15:23:18 using ldconfig in quantal i get libGLESv2.so -> libGLESv2.so.2 Oct 01 15:23:55 ndec_: besides, any news on the omap5 panda side? Oct 01 15:24:09 now running es2_info i get a lib not found error Oct 01 15:24:15 ogra_: If it's not versioned, I'm not sure what you think the symlink will accomplish. Oct 01 15:24:40 ogra_: If the ELF header doesn't have the versioned SONAME in it, you're fighting a losing battle there. Oct 01 15:24:50 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 Oct 01 15:24:59 ppisati: any news? Oct 01 15:25:02 and it worked with the same packaging in precise Oct 01 15:25:13 it's coming soon. Oct 01 15:25:29 infinity, so why do /usr/lib and /lib as well as setting the var just work then ? Oct 01 15:25:49 (and why did it just work in precise as is) Oct 01 15:27:11 ogra_: Dunno. Don't we use update-alternatives for GL/GLES in all the other packages? Oct 01 15:27:13 i could make the package just install to /usr/lib indeed but i would like to know why that works if a subdir doesnt Oct 01 15:27:35 infinity, we do ... doesnt help if ldconfig is so stict though Oct 01 15:27:38 ogra_: And I can't say for sure why yours doesn't work without seeing the package. Oct 01 15:27:55 apt-get source nvidia-tegra Oct 01 15:27:57 (ldconfig hasn't changed at all since precise, so you're barking up the wrong blame tree there) Oct 01 15:28:51 is there any way to get something readable out of objdump so that i can check what ldconfig actually sees ? Oct 01 15:29:04 Hello All Oct 01 15:29:18 janimo: Are you available& Oct 01 15:29:20 ? Oct 01 15:29:55 alex-ac100, yes Oct 01 15:30:16 alex-ac100, I was just told by fly-away about the issue Oct 01 15:30:55 Sorry for bother you, but just would like to let you know that last linux-meta-ac100 build is not correct Oct 01 15:31:18 Ah OK, no issues Oct 01 15:32:30 janimo: I was not awaire that have to talk with you on THIS channel, looking for you on #ac100 since yesterday evening Oct 01 15:32:58 ogra_, if you run ldd /usr/bin/es2_info do you get the paths that should be found? Oct 01 15:33:39 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 Oct 01 15:33:45 janimo, yes, and ? Oct 01 15:34:14 ogra_, are the libGLES ones missing? Oct 01 15:34:17 janimo, its not about the app, its about the lib Oct 01 15:34:53 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 Oct 01 15:35:00 alex-ac100, ah wait the meta build? fly-away told me about NV_SOMETHING option needing turned off or hw accel does not work Oct 01 15:35:06 is this a different issue? Oct 01 15:35:12 in these three cases it works fine Oct 01 15:35:46 ogra_, is the rel16 tarball putting the files in the same place as rel15? Oct 01 15:35:51 yes Oct 01 15:36:27 its exactly identical, just other binaries and a few changes to udev rules and the xorg.conf snippet Oct 01 15:36:32 ogra_: What do you mean "not about the app, it's about the lib"? What does "ldd /usr/bin/es2_info" say? Oct 01 15:37:24 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 Oct 01 15:37:25 ogra_, I know the order of the lines ld.so scripts created/appended to by the postint mattered Oct 01 15:37:36 I know I hated those parts of the package too Oct 01 15:37:53 but I hoped they should all work from now on if we do not touch them anymore Oct 01 15:38:02 janimo: For this reason video playback is broken with this kernel build Oct 01 15:38:04 ogra_: do you know if the libs are providing a valid SONAME? Oct 01 15:38:31 alex-ac100, right. So you mean the new kernel package not the meta? Oct 01 15:38:51 the latter just says which is the actual kernel image deb and does not have any config settings Oct 01 15:38:53 rsalveti, how do i find out ? Oct 01 15:39:04 janimo: I mean this one https://lists.ubuntu.com/archives/quantal-changes/2012-September/010128.html Oct 01 15:39:09 rsalveti, i definitely see the wrong name being used in ldconfig Oct 01 15:39:24 rsalveti, but that didnt change vs precise ... thats my issue Oct 01 15:39:32 ogra_: objdump -x lib | grep SONAME Oct 01 15:39:38 alex-ac100, ok, the config issue. I was just confused by you mentioning meta (the namings are confusing for newcomers too so no problem) Oct 01 15:39:42 the lib is the same way broken as in the former version Oct 01 15:40:00 ogra_: were you using update alternatives at the previous version? Oct 01 15:40:05 yes Oct 01 15:40:22 its the same package, i only replaced the binary blobs Oct 01 15:40:26 janimo: Sorry, I'm not familar with terminology, so my mistake Oct 01 15:40:56 alex-ac100, yes, no prob, as I said confusing package names :) Oct 01 15:41:17 ogra_: by default the gl applications will look for the .so.xx libs, but I suppose you already got the links in place, right? Oct 01 15:41:26 rsalveti, yep Oct 01 15:41:30 just because I saw a few gles libs just providing the .so one in the past Oct 01 15:41:35 and that caused run time issues Oct 01 15:41:56 ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ objdump -x usr/lib/libGLESv2.so |grep SONAME Oct 01 15:41:56 SONAME libGLESv2.so Oct 01 15:41:56 ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0 Oct 01 15:42:02 the problem with the lack of sonames is more if you decide to build something with it Oct 01 15:42:17 yup, no version there Oct 01 15:42:24 wait Oct 01 15:42:27 gets better Oct 01 15:42:34 ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ objdump -x usr/lib/libGLESv2.so |grep SONAME Oct 01 15:42:35 ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ Oct 01 15:42:39 The lack of proper SOVER will confuse the crap out of ld.so Oct 01 15:42:53 infinity: even at runtime? Oct 01 15:42:55 so apparently ld works fine if there is no SONAME at all Oct 01 15:43:21 rsalveti: Yes, cause ld won't map the symbols correctly. Oct 01 15:43:32 hm, it might be the case that having SONAME but without version might be causing issues there Oct 01 15:43:43 ye, it does Oct 01 15:43:54 but why is just the link used if there is no SONAME ? Oct 01 15:44:07 the lib lives in the same taret place in both packages Oct 01 15:44:13 *target Oct 01 15:44:26 with the same linakge Oct 01 15:44:31 infinity: could be, but I believe it'd probably work in this case Oct 01 15:44:38 *linkage Oct 01 15:44:41 the libs are supposed to be fully compatible :-) Oct 01 15:45:23 ogra_: ldconfig sets up links based on SOVER. Oct 01 15:45:27 also why does it work in /usr/lib ? Oct 01 15:45:58 ogra_: Working in /usr/lib is probably a red herring, but let me look at this in a bit. Oct 01 15:46:04 ogra_: at the pvr-omap4 one I also had to remove the rpath from the libs Oct 01 15:46:08 to get it to work properly Oct 01 15:46:40 Oh, if it has an RPATH, that would explain the /usr/lib thing. Oct 01 15:46:52 well, i think i would break the license if i touched the binary Oct 01 15:47:10 ogra_: can you list the rpath available at your library? Oct 01 15:47:13 not necessarily Oct 01 15:48:09 ogra_: chrpath -l lib.so Oct 01 15:48:52 I think at the pvr-omap4 case it had /usr/lib in it Oct 01 15:49:00 ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so Oct 01 15:49:00 `usr/lib/libGLESv2.so' probably isn't a 64-bit LSB-first ELF file. Oct 01 15:49:00 elf_open: Exec format error Oct 01 15:49:02 (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 Oct 01 15:49:02 GRRR Oct 01 15:49:09 one sec Oct 01 15:49:27 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 Oct 01 15:50:06 ogra_: please try 'find usr/lib -maxdepth 1 -iname "*.so*" -type f -exec chrpath -d {} +' Oct 01 15:50:22 and see if it works better Oct 01 15:50:36 infinity: well, we're just removing stuff from the library :P Oct 01 15:50:41 not adding anything hehe Oct 01 15:50:51 ogra@sabre:~/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so Oct 01 15:50:51 usr/lib/libGLESv2.so: no rpath or runpath tag found. Oct 01 15:51:18 ogra_: for all libs? Oct 01 15:51:22 check the libEGL one Oct 01 15:52:06 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) Oct 01 15:52:42 That said, the nvidia upstream for the x86 drivers is a completely different group than for the ARM ones. Oct 01 15:52:46 For reasons I'll never understand. Oct 01 15:53:07 rsalveti, yes, for all libs Oct 01 15:53:28 infinity: hehe, true Oct 01 15:53:29 so now the 1mio $ question ... is there a way ro wipe the SONAME ? Oct 01 15:53:37 *to Oct 01 15:54:00 the interesting thing is that it's working on the /usr/lib and /lib paths Oct 01 15:54:06 right Oct 01 15:54:09 janimo: well not 100%, but when this nvavp option is activated, kernel tried to looad some firmware file Oct 01 15:54:16 load Oct 01 15:54:25 ogra_: I think there might be a way to wipe it out Oct 01 15:54:27 alex-ac100, then maybe we just need to package that firmware file too? Oct 01 15:54:43 it should be fwiw Oct 01 15:54:48 This firmware is not include in R16 package Oct 01 15:55:13 alex-ac100, at least this does not sound scary from the description: Oct 01 15:55:16 http://paste.ubuntu.com/1254125/ Oct 01 15:55:17 janimo: and this firmware in not necessary Oct 01 15:55:19 alex-ac100, that will likely be in the codecs package Oct 01 15:55:31 ogra_, should we package those too? Oct 01 15:55:32 ogra_: what is the issue specifically, you're not able to find it at runtime? Oct 01 15:55:39 janimo, i would like to :) Oct 01 15:55:40 put them in linux-firmware? Oct 01 15:55:43 ogra_: even when forcing the ld path? Oct 01 15:55:47 rsalveti, right Oct 01 15:56:03 janimo: ogra_ no, I tested with some custome kernel build without this config settings Oct 01 15:56:12 as said above it works with LD:LIBRARY_PATH (which likely just overrides ld here and uses the links) Oct 01 15:56:28 Hardware Video playback worked fine on that build Oct 01 15:56:39 k Oct 01 15:56:42 WITHOUT that file Oct 01 15:57:45 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 Oct 01 15:58:13 loading Oct 01 15:59:09 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). Oct 01 15:59:56 stuw, ok I will remove it from the next upload Oct 01 16:00:07 janimo, thx Oct 01 16:00:25 ogra_: I'm stuck tethering this morning, but I'm downloading things as fast as I can to have a quick poke around. :P Oct 01 16:00:54 infinity, i'll push the r16 package somewhere too for comparison Oct 01 16:01:18 ogra_: Oh, yes, please do. Oct 01 16:01:48 * ogra_ wants a chsoname tool :P Oct 01 16:02:07 That may not be the issue. Especially if, as you claim, it works with different paths. Oct 01 16:02:13 But I want to look at it all first. Oct 01 16:02:36 (Well, it may not be the only issue... It *is* an issue that the library has a broken SONAME, but...) Oct 01 16:02:59 well, the former oversion doesnt have a SONAME at all and works :) Oct 01 16:03:37 ogra_: did you try running with LD_DEBUG to see if that would help? Oct 01 16:03:51 ah, no, not yet Oct 01 16:04:15 what should i run that way ? ldconfig or es2_info Oct 01 16:04:39 es2_info Oct 01 16:04:44 k Oct 01 16:05:34 LD_DEBUG=files Oct 01 16:05:47 LD_DEBUG=init Oct 01 16:05:51 and others as well Oct 01 16:06:50 I still kinda want to know what the output of ldd is/was. Oct 01 16:07:03 But meh. Give me packages, and I can debug myself. Oct 01 16:07:25 infinity, http://people.canonical.com/~ogra/tegra/nvidia-graphics-drivers-tegra* Oct 01 16:08:10 so with ÖD_LIBRARY_PATH set i see direct_opencount=1 for libGLES Oct 01 16:08:25 without the var set it properly tells me it cant find the lib Oct 01 16:08:46 Can't find the lib is a bit odd, since mesa installs one. Oct 01 16:08:52 So, something's gone horribly wrong. Oct 01 16:09:38 Also, installing the 15.1.0-0ubuntu1 version in my chroot just failed... Oct 01 16:09:38 err, no, we have overriden the mesa install path from ld with an alternative Oct 01 16:10:18 update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory Oct 01 16:10:21 update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory Oct 01 16:10:25 Brilliant. Oct 01 16:10:28 Also, double-paste. Bleh. Oct 01 16:10:41 http://paste.ubuntu.com/1254162/ http://paste.ubuntu.com/1254166/ Oct 01 16:10:58 first is without, second with LD_LIBRARY_PATH set Oct 01 16:11:04 (ldd output) Oct 01 16:11:25 ogra_: So, uhm. This package is missing a dependency... Oct 01 16:11:28 infinity, werid, no idea wheer that comes from Oct 01 16:11:39 oh ? Oct 01 16:12:07 ogra_: Likely on xorg-video-abi-13. Oct 01 16:12:23 the r16 package has it Oct 01 16:12:31 15 didnt, right Oct 01 16:12:34 Ahh, kay. So, fixed in future. :P Oct 01 16:12:39 yeah :) Oct 01 16:12:40 Let me install an xserver and try again. Oct 01 16:12:51 precise didnt complain about that ... Oct 01 16:12:55 (lintian didnt) Oct 01 16:13:02 iirc now it does Oct 01 16:13:08 No, but installing in a bare chroot sure complains. Oct 01 16:13:10 (See above) Oct 01 16:13:14 yeah Oct 01 16:14:33 Oh, still broken. Oct 01 16:14:56 Your package should probably also ship the /usr/lib/xorg/modules/drivers/ directory... Oct 01 16:15:25 Otherwise, the postinst only works if one has other X drivers installed. :P Oct 01 16:15:28 Which is a bit silly. Oct 01 16:15:54 btw http://paste.ubuntu.com/1254177/ Oct 01 16:16:03 ldd with the lib in /usr/lib Oct 01 16:16:39 infinity, hmm, the tarball does, weird i thought the package would just use that ... i'll add it to .dirs Oct 01 16:17:09 ogra_: Also, while I'm nitpicking, arm-linux-gnueabi_EGL.conf should be gnueabihf_EGL Oct 01 16:17:20 infinity, r16 ;) Oct 01 16:17:27 already fixed Oct 01 16:17:46 That could be where your problem lies. Oct 01 16:17:58 no, i'm installin on a virgin ac100 Oct 01 16:18:07 Since eabihf_EGL is an alternative shared by mesa. Oct 01 16:18:10 The other one wasn't. Oct 01 16:18:29 eabi_EGL was until precise Oct 01 16:18:39 but only on armel :) Oct 01 16:18:44 for which we dont build Oct 01 16:18:50 (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# ls Oct 01 16:18:50 arm-linux-gnueabi_EGL.conf arm-linux-gnueabihf.conf arm-linux-gnueabihf_EGL.conf libc.conf Oct 01 16:18:53 Yes, well. Oct 01 16:19:12 My point is that in the above scenario, we get arm-linux-gnueabi_EGL.conf parsed first (which has what you want in it). Oct 01 16:19:26 Once you set up the correct alternatives, it may be doing something you didn't expect. Oct 01 16:19:27 right, but that file is gone in r16 Oct 01 16:19:33 But I'll find out once I build your binaries. Oct 01 16:19:48 ogra_: I know the file should be gone in r16, I'm saying that might be your problem. :P Oct 01 16:19:50 oh. i can push my binary for you as well ... Oct 01 16:20:05 ogra_: Too late, sbuild's finished installing build-deps. :P Oct 01 16:20:11 I assume the build itself is a few seconds. Oct 01 16:20:16 yep Oct 01 16:20:26 pretty niosy about the symbols :) Oct 01 16:21:31 just for completion, there is no arm-linux-gnueabi_* file in my /etc/ld.so.conf.d (and never was on this install) Oct 01 16:22:07 (helps to have three ac100's :) ) Oct 01 16:25:57 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 Oct 01 16:26:33 * ogra_ glares at http://paste.ubuntu.com/1254177/ Oct 01 16:27:04 intresting that it loads all the other libs from /usr/lib/nvidia-tegra ... just not EGL and GLES Oct 01 16:29:44 ogra_: yes, wake up works better with tegra drivers Oct 01 16:32:59 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 Oct 01 16:33:00 objdump: usr/lib/libnvrm_impl.so: File format not recognized Oct 01 16:33:00 0 Oct 01 16:33:00 ... Oct 01 16:33:08 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 Oct 01 16:33:09 57 Oct 01 16:33:09 ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ Oct 01 16:33:28 so it seems nvidia tried to be nice and added SONAMEs all over the place ... Oct 01 16:33:40 just that they didnt add any versioning ... Oct 01 16:33:52 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 Oct 01 16:33:52 0 Oct 01 16:39:38 * ogra_ thinks he should just install libEGL.so and libGLESv2.so (and their links) to /usr/bin and be done Oct 01 16:39:55 or link them there or so Oct 01 16:40:16 the mesa ones wont be used because we override the alternative Oct 01 16:41:35 infinity, ^^^ do you think that could cause any havoc ? Oct 01 16:43:03 * ogra_ goes to find some coffee Oct 01 16:43:15 ogra_: would probably cause issues with any gles software you might build there Oct 01 16:43:31 remember that once you built with a wrong SONAME, things get messy Oct 01 16:44:12 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 Oct 01 16:44:33 it wont make the release if i dont get it in somehow Oct 01 16:45:05 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 Oct 01 16:45:53 rsalveti, also wouldnt builds use mesa anyway ? Oct 01 16:46:14 ogra_: Uhm, your alternatives still seem broken here. Oct 01 16:46:26 infinity, in what way ? Oct 01 16:46:52 ogra_: In that I still have a arm-linux-gnueabi_EGL.conf with the r16 package. Oct 01 16:47:08 the broken soname would affect us even with the right and multi-arch compatible path Oct 01 16:47:18 http://paste.ubuntu.com/1254227/ Oct 01 16:47:29 thats how it looks for me Oct 01 16:47:31 so I don't think there's any easy way out here Oct 01 16:47:34 did you uninstall r15 ? Oct 01 16:47:53 ogra_: I just built and installed from your sources. Oct 01 16:48:04 we should probably just try to get this working with multi-arch and update-alternatives and get it to the archive Oct 01 16:48:27 rsalveti, but how without hacking the SONAME ? Oct 01 16:48:46 we first need to understand if that's really the issue Oct 01 16:48:58 we currently don't know what is happening :-) Oct 01 16:49:11 well, its the obvious difference between r15 and r16 Oct 01 16:49:46 (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# update-alternatives --list arm-linux-gnueabihf_egl_conf Oct 01 16:49:49 /usr/lib/arm-linux-gnueabihf/mesa-egl/ld.so.conf Oct 01 16:49:50 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 Oct 01 16:50:11 Before we faff about SONAMEs, let's address this business. :P Oct 01 16:50:42 ogra_: Are your local sources different from the ones you pointed me at? Oct 01 16:50:58 just checking that Oct 01 16:51:12 --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/nvidia-tegra/ld.so.conf 9000 Oct 01 16:51:23 thats in my current postinst Oct 01 16:52:13 Yeah, that's not what I have here. Oct 01 16:52:20 ah, super sorry Oct 01 16:52:31 Also, your prerm will need to both remove the old and new ones, but maybe it does in your version. Oct 01 16:52:56 not yet, but i'm aware Oct 01 16:53:09 Let me do this by hand and see where it lands me. Oct 01 16:55:55 Alright, that gets me to your breakage now. Oct 01 16:57:18 Hrm. Oct 01 16:57:20 ln -s /usr/lib/nvidia-tegra/libGLESv2.so.2 /usr/lib/ Oct 01 16:57:24 ^-- That really shouldn't work. Oct 01 16:57:28 But it does. Grr. Oct 01 16:58:53 And LD_DEBUG=all just shows that it's not using /usr/lib/nvidia-tegra in the search path at all. Oct 01 16:59:03 So, not necessarily the SONAME to blame here. Oct 01 17:00:27 werid, because ldconfig -v just lists the libs fine Oct 01 17:01:09 i get: libGLESv2.so -> libGLESv2.so.2 Oct 01 17:01:25 (note the wrong order due to the SONAME) Oct 01 17:01:30 I don't... Oct 01 17:01:37 I don't get it listed at all. Oct 01 17:01:55 Or, I can't type. Oct 01 17:01:56 well, i do, probably your alternatives are still wonky ? Oct 01 17:02:33 The thing is, linking it in /lib doesn't change the wonkiness of that so -> so.2 thing. Oct 01 17:02:39 It just starts showing up in searched. Oct 01 17:02:39 with LD_DEBUG i see that libGLESv2.so.2 gets directly loaded when in /usr/lib Oct 01 17:02:45 seaches* Oct 01 17:02:58 right Oct 01 17:03:17 it will make binaries work :) Oct 01 17:03:53 Yeah, but. That doesn't tell me anything about what's wrong. Oct 01 17:05:04 * infinity compares a chroot with r15 to one with r16 to sort this out. Oct 01 17:05:25 nothin is worng (apart probably from being able to force loading of a lib if i put it in /usr/lib) Oct 01 17:05:36 ld does the right thing Oct 01 17:05:45 Which right thing is that? Oct 01 17:05:58 using the SONAME and caching the lib info with it Oct 01 17:06:16 its not ld's fault that the SONAME has no version number Oct 01 17:06:29 Well, yes, that's the right thing, but that shouldn't relate to search paths. Oct 01 17:06:41 oh, still taht Oct 01 17:06:51 sorry, thought you solved that bit yet Oct 01 17:07:16 No, if it was searching the path, it would work. Oct 01 17:07:22 That's how it finds it when it's in /lib Oct 01 17:08:20 oh, inbtresting ... ldconfig -v with the lib in both places shows me the SONAME issue for both even Oct 01 17:08:32 ogra_: Yeah, I said that earlier. Oct 01 17:08:37 ah Oct 01 17:14:31 Okay, so looks like two bugs. Oct 01 17:14:44 One is the library having the wrong SONAME, which means it won't land in the cache. Oct 01 17:14:54 right Oct 01 17:15:00 The other is that ld.so doesn't search the extended path, only ldconfig. Oct 01 17:15:10 oh Oct 01 17:15:21 and that changed since precise ? Oct 01 17:15:28 So, ldconfig will search the path and add "correct" libraries to the cache. But our library is broken, so it doesn't get cached. Oct 01 17:15:43 Later, ld.so searches the cache, finds nothing, and then walks the built-in directories it knows about. Oct 01 17:15:48 No, it didn't change. Oct 01 17:15:56 The r15 library gets cached. Oct 01 17:16:02 And found from the cache. Oct 01 17:16:06 So no walking required. Oct 01 17:16:13 it doesnt have a SONAME Oct 01 17:16:26 Yes, which is apparently better than having an incorrect one. :P Oct 01 17:16:32 lol Oct 01 17:16:33 yeah Oct 01 17:16:37 obviously Oct 01 17:16:59 so do you know any trick to wipe the SONAME field (or ven fix it) Oct 01 17:17:01 *even Oct 01 17:17:33 If there's padding in the ELF header, you could fix it. Oct 01 17:17:37 Check with a hex editor. Oct 01 17:20:52 padding would be zeros ? Oct 01 17:21:09 Yeah. Oct 01 17:21:22 hexedit doesnt really show anything usable on the right ... Oct 01 17:21:35 and there seem to be no zeros at the start of the file Oct 01 17:23:25 GCC: (crosstool-NG hg_unknown@20110628.165246) 4.5.3 Oct 01 17:23:27 heh Oct 01 17:23:30 4.5 Oct 01 17:24:59 Boom, easily fixed. Oct 01 17:25:08 ?? Oct 01 17:25:12 There's a bunch of nulls after GLIBC_2.4 Oct 01 17:25:30 yep, i see them Oct 01 17:25:48 e_match.__cxa_call_unexpected.libGLESv2.so.GLIBC_2.4................ Oct 01 17:25:52 So, you replace libGLESv2.so\0GLIBC_2.4\0\0 with libGLESv2.so.2\0GLIBC_2.4 Oct 01 17:25:55 And it all magically works. Oct 01 17:26:26 The same needs to be done for libEGL.so.1 as well. And who knows what else. Oct 01 17:26:38 A quick binary patching script to fix it up in the build wouldn't be much effort. Oct 01 17:26:40 only the two to make binaries work at least Oct 01 17:26:54 And would be the more "correct" fix anyway. Oct 01 17:26:57 As annoying as it is. Oct 01 17:27:21 >/me has never done somethin like this, do you know odf an example ? Oct 01 17:29:25 (i manage editing with hexedit indeed, but have no idea how i would have to script that) Oct 01 17:31:20 sed -i -e 's/libEGL.so\x00GLIBC_2.4\x00\x00/libEGL.so.1\x00GLIBC_2.4/' /usr/lib/nvidia-tegra/libEGL.so Oct 01 17:31:32 you can sed that ?!?!?! Oct 01 17:31:36 geez Oct 01 17:31:39 ^-- That seemed to DTRT for my libEGL, cook as appropriate for others. Oct 01 17:32:01 ogra_: Requires GNU sed (\x00 is a GNU extention), but we don't ship any other POSIX seds anyway, so whatever. Oct 01 17:32:10 * ogra_ wouldnt have thought of sed ... probably some dd and cat weirdnesses, but not sed :) Oct 01 17:33:10 Hrm, that might not have worked actually. sed may have broken it. Oct 01 17:33:21 Was good enough for ldconfig, not good enough for ld.so. :P Oct 01 17:33:30 (While hand-editing was good enough for both...) Oct 01 17:33:48 There was a nice C-based binary patches in LRM, back when LRM still existed. Oct 01 17:33:49 yeah, i'm still poking bytes here Oct 01 17:33:54 I can try to dig it up in a bit. Oct 01 17:34:12 Oh wait. Hahaha. Oct 01 17:34:16 No, it's not that sed broke it. Oct 01 17:34:18 well, worst case i change it while repackaging the updatream tarball Oct 01 17:34:24 *upstream Oct 01 17:34:44 It's that other libraries are linked to libEGL.so, which doesn't exist once I've done that. Oct 01 17:34:52 i have to do that anyway to match the format of the package Oct 01 17:35:02 So braindead. Oct 01 17:35:14 oh, indeed, all libs use the broken sonames :) Oct 01 17:36:05 * infinity head -> desk. Oct 01 17:36:23 So, monkey-patching the SONAMEs won't work, since while that fixes all OUR binaries, it breaks all of THEIRS. Oct 01 17:36:29 Brilliant. Oct 01 17:36:33 btw, is there any particular reason that ld doesnt search additional dirs ? Oct 01 17:37:09 Other than it being painfully slow to make ld.so parse a conf.d directory for run-time configs, no. Oct 01 17:37:13 It's meant to trust the cache. Oct 01 17:37:19 k Oct 01 17:37:27 Which would work, if the cache was caching libraries that weren't insane. Oct 01 17:37:34 heh Oct 01 17:39:10 Do you have a good enough rapport with upstream to just get them to fix their SONAMEs? Oct 01 17:39:40 Cause this is going to end up on our end with either a mess of incorrect symlinks, or monkeypatching and a few incorrect symlinks. Oct 01 17:39:43 Neither is pretty. Oct 01 17:39:43 not in time Oct 01 17:39:48 And neither is correct. Oct 01 17:40:16 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. Oct 01 17:40:29 Well, maybe you could patch the NEEDED section in everything too... Oct 01 17:40:52 well, as i said in the beginning, i would just install EGL and GLES to /usr/lib Oct 01 17:41:10 Yeah, or that. Still broken. :/ Oct 01 17:41:13 all others arent versioned at all and are only used by these two Oct 01 17:41:36 yes, but once there is a fix i wont have to fiddle with symlinks ... Oct 01 17:41:57 the files would just move to lib/nvidia-tegra and ldconfig woudl pick up the change Oct 01 17:42:02 I'd still like to talk to upstream about doing it right. Oct 01 17:42:40 i'll surely poke srwarren about it but he's despite being my contact not the maintainer Oct 01 17:42:43 do you guys have plans for firefox-18? Oct 01 17:43:30 mjrosenb: When it's the current version, sre. Oct 01 17:43:32 s/sre/sure/ Oct 01 17:44:36 damned, now how do i save a file in hexedit ... Oct 01 17:44:37 infinity: that turns on ionmonkey, which is not armhf friendly Oct 01 17:44:45 pressing a key tells me F1 for help ... Oct 01 17:44:58 F1 indeed gives me the gnome terminal help :P Oct 01 17:45:15 ogra_: I dunno, I use ghex, which appears to have sane menus. Oct 01 17:45:32 ogra_: That said, sed was doing the right thing for me. It was just the NEEDED sections in OTHER libs that were still broken. Oct 01 17:45:56 (As in, some of the little support libs are linked against "libEGL.so") Oct 01 17:46:17 mjrosenb: I've not looked into it or heard much about it. How not friendly is it? Oct 01 17:46:26 ah, ctrl-x Oct 01 17:47:01 infinity: it should need minimal modifications, but I'm considering leaving that up to a student/contributor, which means it may never get done Oct 01 17:48:34 rsalveti: ^-- Something for your team to poke at? Oct 01 17:50:50 janimo: You around? Oct 01 17:50:56 infinity, yes Oct 01 17:51:06 * janimo wonders what he broke now Oct 01 17:51:20 janimo: precise armadaxp. It's an ABI bump, but no meta. Oct 01 17:51:49 ah, the SRU right? Oct 01 17:51:58 janimo: Also, don't set promote-to-proposed tasks to Fix Released if you do the copy yourself. Cause, well. It's in the queue, and not done. :P Oct 01 17:52:01 janimo: Yes. Oct 01 17:52:16 ok, I usually waited to see the package building before uploading the meta Oct 01 17:52:21 janimo: (Really, no need to do the copy yourself anyway, I notice when they need to be done, and I need to babysit them anyway) Oct 01 17:52:40 janimo: Erm, "see it building"? You already copied it to the archive! Oct 01 17:52:44 infinity, ok. I think when I did the first SRUs at the beginnning of Q I was told I should copy them Oct 01 17:52:48 or they'd languish there Oct 01 17:52:54 Yeah, you were lied to. ;) Oct 01 17:53:21 (You can copy if you like, but it just ends up in the queue and someone needs to manually do overrides anyway, I prefer to do it all when I know what's going on) Oct 01 17:53:55 ok, I will not copy from now on, not sure why I was asked too Oct 01 17:54:09 janimo: Anyhow, copying yourself or not, please never do the copy until after all support packages (only meta in your case) are also done, so they can all copy together. Oct 01 17:54:35 infinity, ok. I always thought it's ok to have the linux-image package there without meta Oct 01 17:54:41 janimo: Since promote-to-proposed assumes the whole thing as a block (lbm/linux/meta/etc) Oct 01 17:54:46 as it does not get upgraded to anyway until meta is there no? Oct 01 17:55:03 ah, I had no idea about that promote contract Oct 01 17:55:21 it makes sense, just I did not encounter it so far Oct 01 17:55:29 janimo: Even in devel releases, I prefer if it happens this way, but for SRUs, we have a pretty strict way of doing things. Oct 01 17:55:55 janimo: For devel releases, I'd still rather see kernel/meta go to proposed together, instead of this "we have two kernels in the archive, and one's NBS" thing. Oct 01 17:57:20 janimo: Anyhow. meta the PPA up for me, if you please. I'm going to reject the current copy for the sake of my own sanity and reset the task, and I'll do the whole thing together later. Oct 01 17:57:49 infinity, ok, will do Oct 01 17:57:53 Oh, feh. I can't reset the task. Oct 01 17:58:05 I'll just reassign it to me and remember to do it later. :P Oct 01 18:13:41 hmm, so i manage to empty the SONAME field, but i cant make it vanish Oct 01 18:14:28 oh, and an empty SONAME really makes ld dizzy :) Oct 01 18:21:42 infinity, We do have a bug to add (correct) sonames to the libraries, and it's also possible we half-implemented it but with bogus values. anyway, I'll track down the bug and put comments there indicating the problem. Oct 01 18:21:55 (from #ac100) Oct 01 18:22:13 infinity, meta built in ppa Oct 01 18:22:24 janimo: I noticed, thanks. Oct 01 18:22:49 swarren no chance to use cmake or autotools with libtool? Oct 01 18:22:50 woglinde, no, we build the libraries with the same tools for Android, Linux etc. Oct 01 18:22:50 and hence someone developed custom makefiles for it all. Oct 01 18:22:55 now thats lovely Oct 01 18:23:34 Meh, if they figured out how to put some sort of SONAME in there, they can figure out how to make it right. :P Oct 01 18:23:37 Not rocket science. Oct 01 18:23:45 heh, indeed Oct 01 18:23:56 * janimo is tempted to save the backlog of the past hours of conversation on this list for future historians who may be interested in the ways people at the beginningof 21st century struggled to convey straightforward things due to error prone and inexpressive tools at their disposal Oct 01 18:24:16 to computers Oct 01 18:24:21 infinity, well, i told him if he manages to get me a rebuild til thu it will make it in (given there are no other bugs) Oct 01 18:24:28 lets see Oct 01 18:24:37 he is very concerned Oct 01 18:25:05 (srwarren is a good guy ... he's also active on cross-distro ) Oct 01 18:43:40 infinity, given that the driver works just fine and only the libs are affected i'm pondering to upload as is ... while GLES doesnt work then, HDMI works and xorg only uses 1/10h of ram Oct 01 18:43:52 *1/10th Oct 01 18:44:23 that should also make SRUing an upstream fix easy Oct 01 18:45:13 * ogra_ will put the current package on the shelf for thu ... if nvidia manages i can still update the tegra_bins tarball quickly Oct 01 20:59:14 janimo: I'm afraid, but this ac100 3.1.10-5-ac100 #8 kernel build is not correct again Oct 01 20:59:44 alex-ac100, what is missing? Oct 01 21:04:01 janimo: TEGRA_AVP_KERNEL_ON_MMU=y Oct 01 21:04:38 alex-ac100, can you clone the git tree and build the package yourself? Oct 01 21:04:50 did you build marvin's ? Oct 01 21:05:10 TEGRA_AVP_KERNEL_ON_MMU=y is correct, no ? Oct 01 21:05:15 no idea Oct 01 21:05:35 it is, but not set in last build Oct 01 21:05:37 well, afaik it is Oct 01 21:05:40 they have many cryptic config names which I do not know what they stand for Oct 01 21:05:41 ah Oct 01 21:05:54 same here Oct 01 21:06:14 well, fly-away isnt here, he fiddled with all that multimedia playback stuff Oct 01 21:06:47 (he is in #ac100 though) Oct 01 22:47:29 ogra_: infinity: I don't think sed would work there Oct 01 22:47:35 because the size is different Oct 01 22:47:42 and the elf headers stack size would probably change Oct 01 22:47:53 breaking some other stuff Oct 01 22:48:26 so I believe the easiest way to handle that is to handle the pain of having the libs at the standard locations Oct 01 22:48:43 such as /usr/lib, and get that bug opened for nvidia to handle later Oct 01 22:50:30 rsalveti: The sed I gave him didn't change the size. Oct 01 22:51:09 rsalveti: But there's breakage in their other libs havng the unversioned .so in NEEDED, so yeah. It's all pretty FUBAR. ;) Oct 01 22:52:03 infinity: oh, true, luckly there was \0\0 Oct 01 22:52:14 yeah, that's expected as well Oct 01 22:52:33 in android nobody cares about sonames Oct 01 22:52:46 actually, nobody cares about anything that's vendor/hardware specific :-) Oct 01 22:53:11 the problem is that then the vendor ends up using the same solution everywhere else :-) Oct 01 22:55:37 rsalveti: I'm fairly confident they'll fix it for Oli, the question is if they'll do it in a timely fashion. ;) Oct 01 22:56:13 * infinity thinks he should take an afternoon nap and sleep off this cold/flu/whatever. Oct 01 22:56:54 yeah, not for quantal, for sure **** ENDING LOGGING AT Tue Oct 02 02:59:58 2012