<    June 2018     >
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 _2_2 23  
24 25 26 27 28 29 30
00:00 <awilfox> staticfloat: multilib is not supported; you need to make a 32-bit chroot and run 32-bit softwares in there
00:01 <awilfox> cfriedt: subpackages can define depend= in their functions (i.e. go() { depend="go" .... }), but if it already requires go for a .so file abuild will find that automatically
00:02 <cfriedt> swilfox: thanks!
00:02 <awilfox> glad to help :)
00:05 cfriedt left
00:08 <staticfloat> Thanks awilfox. I guess the easiest way for me to get what I want is to just download and extract `/lib/ld-musl-i386.so.1` and `lib/libc.musl-x86.so.1` from the `.apk` files directly.
00:09 <staticfloat> I don't want to have to live in a chroot, I just want to be able to run `i686` and `x86_64` binaries within the same system. This seems to work just fine, and as I'm not planning on installing many other libraries, it should be fine.
00:10 <awilfox> whatever works for you :) dunno how you will get the libs to coexist though, since there is no /lib32 or /lib64
00:14 mickibm joined
00:15 wener joined
01:25 roben joined
01:31 kolbyjack joined
01:31 kolbyjack joined
01:41 <staticfloat> The `musl` libraries are named differently for different architectures (because the interpreter that gets baked into ELF executables must exist at a predefined location; so they have had a solution to this multilib/multiarch problem for a long time)
01:42 <staticfloat> So you get things like `/lib/ld-musl-i386.so.1` and `/lib/ld-musl-x86_64.so.1`
01:44 <staticfloat> So those co-exist fine. For libraries that are loaded by the system dynamic linker, it's not normal for them to have the architecture embedded within the filename, but the system dynamic linker (In this case, `musl` itself) is smart enough to know about multiple search paths, so it will keep looking through the paths that are defined within the sy
01:44 <staticfloat> stem to try and find one that it can link into the requesting binary. So if I try to run `foo-` which is an `i686` executable and which relies on `libz.so.1`, but `/lib/libz.so.1` is of architecture `x86_64`, it will skip over it, and move on. So I just have to add my own `/lib32` or similar to the default search paths and drop all my 32-bit libr
01:44 <staticfloat> aries within there, and things should work "just fine"
01:45 <staticfloat> At least, that's my understanding. I hope to not need too many 32-bit libraries. Probably just `libz` and that's it, as most of the binaries I use should be pretty self-contained.
01:45 <staticfloat> Thanks!
01:58 wener joined
02:16 wener joined
02:25 mksully22 joined
03:24 blueness joined
03:34 mickibm joined
04:19 mickibm joined
04:43 mickibm joined
05:38 mickibm joined
05:57 quasinoxen joined
06:23 rdutra joined
06:29 edwarnicke joined
06:30 lostd joined
07:15 clemens3 joined
07:46 tmh1999 joined
10:14 fekepp joined
10:16 tty joined
11:05 wener_ joined