IRC Logs for #crux-devel Sunday, 2013-10-27

Romsterhow can it be a bug if it's not in compat-32 and no one mentioned that steam requires it until now -_-00:50
teK_take it or leave it :-)00:55
*** Amnesia has quit IRC01:08
*** __mavrick61 has joined #crux-devel03:51
RomsterteK_, clean chroot no misisng files in python-3205:48
Romsterdunno what your on about.05:48
*** Amnesia has joined #crux-devel07:45
juefrinnst: thanks, looks like I've missed the new poppler release07:47
jueoh no, it's brand new :)07:47
Romsterwhy is it every other compile of libxml2-python-32 it puts shit in /usr/lib and other times it goes in the proper place /usr/lib32/ stupid configure script07:56
Romsterso what can we do about mesa3d and --enable-texture-float ?08:46
Romsterhttp://irclogs.shortcircuit.net.au/%23crux/2013-10-26.log.html#t08:11:4408:47
*** Amnesia has quit IRC09:09
*** Amnesia has joined #crux-devel09:09
*** nrxtx has joined #crux-devel11:40
*** nrxtx has quit IRC12:37
*** nrxtx has joined #crux-devel12:40
*** deus_ex has quit IRC14:47
*** deus_ex has joined #crux-devel15:03
nrxtxis there some special handling loading dynamic libraries when using 32bit applications?15:32
nrxtxis the 32bit library path hardcoded in crux?15:54
Romstertouch .32bit15:54
Romsterin the ports directory see pkgmk.conf for the 32bit paths15:54
jaegerthere's nothing special you need to do to run most apps if that's what you're asking15:54
*** nrxtx_ has joined #crux-devel15:55
nrxtx_jaeger: at runtime15:56
nrxtx_due to bumblebee i have some 32-bit libs not being in /usr/lib32/15:56
nrxtx_but at all time libraries are loaded from "/usr/lib/../lib32/"15:57
jaegerPreferred would be to fix the port/package but you can probably use LD_LIBRARY_PATH to temporarily add paths15:57
nrxtx_no matter what is in ld.conf-directory15:57
Romsterbumblebee -_-15:57
jaegerwell, 32-bit apps in general work fine. bumblebee is likely the problem here, might need to do some patching15:57
nrxtx_there is the file lib32.conf for ld right?15:59
jaegeryes16:00
nrxtx_isn't it normally used by the dynmic linker to find the libraries?16:02
nrxtx_or am i just confused16:02
jaegeryes, but bumblebee is likely doing something stupid16:04
nrxtx_if i remove lib32.conf run ldconfig should the 32-bit applications stop working?16:05
teK_nrxtx_: your advice did nothelp (wrt passwordless wlan+dhcp)16:07
nrxtx_teK_: doesn't work in all cases at least it worked for vee_16:10
nrxtx_...16:12
nrxtx_jaeger: LD_LIBRARY_PATH gets ignored16:12
nrxtx_that's why its not working with bumblebee16:12
jaegerdon't know what to tell you... test some other 32-bit apps, perhaps, and see if you have a system-wide issue or if it's bumblebee-specific16:15
nrxtx_jaeger: tested it without bumblebee, but seems like LD_LIBRARY_PATH is ignored when there is a lib with the same name in "/usr/lib/../lib32"16:17
nrxtx_libA.so in LD_LIBRARY_PATH=/my/path/ and /usr/lib32/ then /usr/lib32/ always is checked first16:17
nrxtx_for some reason when loading libs "/usr/lib/../lib32" is preferred ahead of lib32.conf and LD_LIBRARY_PATH16:21
nrxtx_jaeger: all 32-bit executables have rpath set to "/usr/lib/../lib32"16:48
nrxtx_at least the ones i have found16:53
jaegerHrmm... how do you show the rpath? I thought readelf and objdump could but I can't find any16:57
nrxtx_objdump -p /usr/bin/... | grep RPATH16:58
jaegerguess I'll need to install some more 32-bit stuff to test, I have nothing with rpath in it currently16:59
nrxtx_http://crux.nu/ports/crux-3.0/compat-32/mesa-demos-32/Pkgfile16:59
nrxtx_for example17:00
nrxtx_http://pastebin.com/sL2vMbHQ17:00
nrxtx_my output17:01
jaegerwell, 64-bit libs and executables do that as well, I really doubt that's the problem17:03
jaegeras ugly as it looks those dumb ../ refs work17:03
*** kris has joined #crux-devel17:04
kristhe 64bit ones do not show any rpath for me17:07
*** nrxtx has quit IRC17:07
*** nrxtx_ has quit IRC17:07
jaegermany don't seem to have it17:08
*** r570 has joined #crux-devel17:10
jaegerhttp://dpaste.com/1431607/17:10
jaegerdoes an ldconfig -v list all the proper libs you need?17:15
nrxtxjaeger: yes, problem only occurs if you have one lib twice17:19
nrxtxand you want to load another with LD_LIBRARY_PATH17:19
jaegerAre you referring to libs with the same name that are 64-bit and 32-bit both or are there libs that are installed in incorrect locations?17:20
jaegerHave you got an strace output showing the wrong loading order?17:21
nrxtxjaeger: just stripped of all rpath form the 32bit binaries no everything runs fine with bumblebee17:22
nrxtxjaeger: i can create one, haven't saved one17:22
jaegerSo it sounds like there are a couple solutions... 1) strip rpath info and 2) fix bumblebee so that it installs libs in the right place17:23
jaegerI'm not particularly familiar with bumblebee so that's a guess17:23
nrxtxjaeger: it is not a problem of bumblbee17:23
jaegerstripping the rpath info undoubtedly has some other consequence17:23
nrxtxsee also the debian problems: https://wiki.debian.org/RpathIssue17:23
nrxtxwhen rpath is set ld_library_path is ignored17:24
nrxtxalso on other distributions http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath17:27
nrxtxdon't know a right solution for this, except stripping the 32/64bit libs and executables manually and hope nothing breaks17:32
nrxtxcmake already removes rpath by default17:32
jaegerI admit I'm not a fan of removing rpath since it's there for a reason17:33
nrxtxbut how is it useful if it simply points to the default lookup location?17:35
jaegerSeems like tweaking things like that always have consequences17:35
jaegers/have/has/17:38
nrxtxjust tested it also: not all 32bit ones have rpath set17:39
jaegermany libs do not as I said17:39
jaegerI would guess executables are the same17:39
nrxtxyes so for now i'll go on and strip them off, is there a possibility to have a hook in pkgmk?17:41
nrxtxat least i'll have to remove them when rpath == /usr/lib or /usr/lib3217:41
nrxtxwhich does not makes any sense anyway17:41
jaegerI may be missing something simple but I still don't understand the problem17:42
nrxtxthe problem is that LD_LIBRARY_PATH will not work correctly when rpath is set17:43
jaegerYes, you said that, but this is the first I've heard of it... which is why I asked about the strace, too17:43
nrxtxso on a nvidia optimus system there are two version of libGL*17:44
nrxtxone is in /usr/lib and one in /usr/lib/nvidia17:44
nrxtxwhen using the hardware acceleration it has to load /usr/lib/nvidia/libGL*17:44
nrxtxwhich does not work when rpath is set, because it's switching it using LD_LIBRARY_PRELOAD17:45
nrxtx*PATH17:45
nrxtxlong story -> rpath set with nvidia optmius -> no 3d or opencl hardware acceleration17:46
jaegerLD_LIBRARY_PATH is definitely not ignored on my system17:49
jaegerit checked /usr/lib32, then /tmp/libtest (which I set with LD_LIBRARY_PATH), and then /lib3217:49
jaegerDoesn't help your problem but it does show that LD_LIBRARY_PATH isn't ignored17:50
nrxtxand your LD_LIBRARY_PATH is /tmp/libtest ?17:50
nrxtxsure17:51
nrxtxwhich executable did you use?17:51
jaegerdoes it matter? picked one with rpath set. in this case glxinfo-3217:51
nrxtxjaeger: check the order with one where rpath is not set: it will be: /tmp/libtest /lib32 /usr/lib3217:53
jaegerIf the order could be controller more finely that could solve the problem17:53
jaegers/controller/controlled/17:53
nrxtxwhat you saw /usr/lib32/ then /tmp/libtest: if there is one libGL.so in /usr/lib32/ it will never check /tmp/libtest17:54
jaegerof course17:54
jaegerseems like a bug should be reported upstream for whatever sets RPATH. librool?17:55
jaegerlibtool17:55
jaegergod damn, I can't type today17:55
nrxtxthat is the problem, rpath is always taken first thus making ld_library_path unusable17:55
nrxtxwhen there is already a library with the same name in /usr/lib32 (rpath-path)17:56
nrxtxjaeger: there is no real upstream, that's why other distributions start stripping them of or for example cmake where it si done by the build system at make install stage18:01
nrxtxso for now i'll just hook into crux build system stripping them off18:03
jaegerI wonder if explicitly forcing the RPATH and RUNPATH would be the proper way to go18:05
jaegerIt would be ugly18:05
nrxtxjaeger: proper way is don't ever use rpath18:05
jaegerLDFLAGS="-Wl,-rpath=<path>,--enable-new-dtags", etc.18:05
nrxtxjaeger: that's what you should not do18:05
jaegerThen why do the upstream builds set it at all?18:06
nrxtxbecause they want the package maintainer to have enough work to do ;)18:06
nrxtxif you have rpath NOT set you can use /etc/ld.so.conf.d/ to freely change your lookup paths18:07
nrxtxrpath forces one path always used first, which cannot be skipped18:08
*** heroux has quit IRC18:18
*** heroux has joined #crux-devel18:19
*** deus_ex has quit IRC18:22
nrxtxthere are some packages having rpath set to their pkgmk work directories :D18:27
nrxtxok on my system it's only llvm :)18:31
*** deus_ex has joined #crux-devel18:37
*** heroux has quit IRC18:49
*** heroux has joined #crux-devel18:50
*** r570 has quit IRC19:35
*** nrxtx has joined #crux-devel19:46
nrxtxjaeger: stripping rpath when rpath = /usr/lib or /usr/lib32 works fine, now everything works, thx for your time19:48
jaegeralright19:51
jaegerwould like to hear others' thoughts on the rpath setup as well when they're around19:51
nrxtxwrote a script verifing and stripping if safe from my complete system. definitly a good idea to hear other opinions. found some rpath showing to the pkgmk-working directories, some are set explicitly that everything works (heavy usage in samba & libreoffice)19:54
*** deus_ex has quit IRC21:51
*** deus_ex has joined #crux-devel22:04
*** nrxtx has quit IRC23:29

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!