ibotlog2html for #crosstool-ng

<< Previous 2015-06-23 Next >>

# 00:39:11 enunes quits : Quit: leaving
# 01:42:58 djerome joins #crosstool-ng
# 03:52:47 alan_o quits : Quit: Leaving
# 04:32:18 djerome quits : Remote host closed the connection
# 07:40:16 diorcety joins #crosstool-ng
# 07:58:16 blueness quits : Ping timeout: 264 seconds
# 08:20:18 blueness joins #crosstool-ng
# 08:28:30 edge226 quits : Ping timeout: 252 seconds
# 08:29:09 edge226 joins #crosstool-ng
# 13:11:18 alan_o joins #crosstool-ng
# 13:14:18 nandub quits : Ping timeout: 252 seconds
# 14:03:23 bhundven hey diorcety
# 14:03:40 diorcety bhundven: hi
# 14:09:29 bhundven It's been a busy few weeks, but not so much for ct-ng. Graduations and family get-togethers...
# 14:09:41 bhundven sighs
# 14:10:52 bhundven I need to get the rest of the samples tested. I have a box at work that has more cpu power then my craptop, and I'll make a build script that goes through the samples. I'll open issues on any build issues. I need to get 1.22.0 out so I can get some other tasks done.
# 14:13:53 smartin_ quits : Ping timeout: 264 seconds
# 14:16:09 smartin_ joins #crosstool-ng
# 14:18:59 Triskelios joins #crosstool-ng
# 14:19:51 Triskelios hey bhundven
# 14:24:20 smartin_ quits : Ping timeout: 252 seconds
# 14:25:11 smartin_ joins #crosstool-ng
# 14:29:45 Triskelios bhundven: re: multilib, ask away
# 14:30:47 bhundven Triskelios: hey! I'm on the bus, almost at work.
# 14:31:34 bhundven Triskelios: also, need to get Ray (mingwandroid) so we can sync up together.
# 14:34:47 smartin_ quits : Ping timeout: 256 seconds
# 14:35:25 smartin_ joins #crosstool-ng
# 14:38:05 mingwandroid joins #crosstool-ng
# 14:41:20 Triskelios mingwandroid: bhundven might still be en route to work
# 14:46:04 mingwandroid Triskelios: no probs.
# 14:46:25 mingwandroid I've not yet got to the bottom of the lib64 folder not existing, it's very strange.
# 14:47:09 mingwandroid I could put the stuff back in to create the folders, except the actual ones that GCC will use instead of some random lib?? where ?? is 32 or 64.
# 14:52:12 Triskelios the stock gcc configs seem to use the lib?? names, which is why I made lib32 a symlink, but it does seem to work without it with your changes
# 15:11:22 Triskelios the odd thing about the race between creating lib64 and populating it with the libstdc++.so symlink is that I thought the gcc final pass happens after glibc is installed, so why doesn't lib64 exist by then
# 15:14:56 bhundven ok
# 15:14:58 bhundven @work
# 15:17:21 bhundven Triskelios and mingwandroid: so we have two pull requests, are these competing or complementary? We can brake this out into github.com/crosstool-ng-multilib project and collaborate to bring this all together, or do you guys already have a battle plan?
# 15:23:38 mingwandroid they're competing really, but 1/2 of mine was written by you anyway ;-)
# 15:23:58 mingwandroid I've no idea why the folder is missing, but I can add back the code to create it.
# 15:24:34 mingwandroid as I said on github, the folder is created before the symlink is made, in fact it is made several times before the symlink for libstdc++ is made so it is very weird.
# 15:25:07 mingwandroid I can quickly (well, in a few hours after work) put code in to create all the multilib-os folders before building proceeds.
# 15:25:45 bhundven mingwandroid: it's my understanding (correct me if I'm wrong) that the default compiler (the one specified by the tuple) uses /lib, and the multilib gets put in /lib{32,64} depending on if the default is 64 or 32 bit.
# 15:25:59 bhundven right?
# 15:26:27 bhundven so, for instance, if the default compiler is x86_64-unknown-linux-gnu
# 15:26:53 bhundven then the multilib x86_32 stuff goes in /lib32
# 15:27:14 bhundven or if it's i686-unknown-linux-gnu, then the multilib x86_64 libs go in /lib64
# 15:27:47 Triskelios mine was just a quick effort to make multilib work with the minimum set of changes to both the scripts and the resulting sysroot, since I was also not terribly familiar with the reasons for why things were in certain locations, though I knew what gcc wanted
# 15:28:36 Triskelios inclined to take mingwandroid's changes and drop mine. I think the race condition we're seeing was just previous masked by external creation of certain directories
# 15:29:24 bhundven another thing that I'd like to see before multilib is getting gcc to a 2-pass build, which might make multilib a bit simpler
# 15:30:09 Triskelios bhundven: with mingwandroid's changes I see lib64 used for the default objects and lib for 32-bit, which was also surprising
# 15:38:42 bhundven ok
# 15:39:49 bhundven Right now, I'm going to get back to testing samples (which I got distracted from) so that I can get 1.22.0 out
# 15:41:15 bhundven once that is done, I have two priorities after the release. 1) switch from 3-pass to 2-pass gcc build and 2) multilib ... there are other tasks, but those two are the highest for 1.23.0.
# 15:46:34 Triskelios okay. I think we have two tasks remaining, which are to resolve the current race condition (the toolchain seems to work fine if I manually fix it), and figure out the lib locations
# 15:47:47 Triskelios the layout you mentioned, lib for the default ABI and lib?? for the non-default one makes sense to me, and I assume other multilib ABIs remain in lib. my original plan symlinked lib32 -> lib/32 to accommodate this
# 15:48:23 Triskelios s,lib,lib/, rather
# 15:50:37 bhundven I mean, we should be taking the default that gcc uses.
# 15:50:56 bhundven forcing it to one way or another that isn't the default will just cause future issues.
# 15:52:52 bhundven because on x86, there is -m64, -m32, and -mx32. mips has a few more wrt abi, and arm is insane.
# 15:53:10 bhundven as well as SH
# 15:53:22 bhundven ... being on the insane side.
# 15:54:33 Triskelios yeah, that's what I meant. are we using lib/ for each multilib name or toplevel lib?
# 16:05:55 diorcety quits : Quit: Leaving.
# 16:07:54 bhundven Triskelios: I'd think we are using the later.
# 16:08:15 bhundven Triskelios: I will take another look at 6pm PST
# 16:08:28 bhundven -08:00
# 16:08:32 Triskelios the majority of MULTILIB_OSDIRNAMES in gcc/config/*/* do seem to agree, though it's not completely consistent either
# 16:08:46 Triskelios ok, thanks
# 16:09:27 Triskelios prior to either of our changes the scripts definitely tried to use lib/ fwiw
# 16:12:36 mingwandroid Sorry guys, been in a meeting.
# 16:13:01 mingwandroid if your arch is 64-bit then lib is 64-bit and lib32 is 32-bit
# 16:13:16 mingwandroid if your arch is 32-bit then lib is 32-bit and lib64 is 64-bit
# 16:14:33 Triskelios mingwandroid: and other variants like x32 end up in libx32, which seems to be what gcc wants based on the various files under gcc/config/
# 16:14:40 mingwandroid my patches don't force or guess any of this, they ask GCC instead --print-multios or whatever.
# 16:15:39 Triskelios mingwandroid: right now, your changes appear to put 64-bit objects in lib64 even though I'm building for a 64-bit target
# 16:17:08 mingwandroid Triskelios: ah yeah you are right, well that's what GCC gave us back anyway, so the gcc/config wants it that way I guess ..
# 16:17:14 mingwandroid Triskelios: so yeah, what you said :-)
# 16:17:32 mingwandroid Btw, I just built multilib linux target on Windows.
# 16:18:01 mingwandroid .. and the libstdc++ race condition didn't happen (but actually, ln is implemented as cp there anyway)
# 16:18:28 Triskelios heh. I should try to build on illumos, so I can actually dtrace the thing if it fails
# 16:19:18 bhundven Triskelios: :)
# 16:19:47 mingwandroid use the best tool for each job .. though with that in mind, why do I do 90% of my computing on Windows?
# 16:20:53 bhundven I've been wanting to port ct-ng to haiku-os (prev BeOS) for some time :)
# 16:21:14 bhundven I also just got a chromebook...
# 16:21:27 mingwandroid heh, I put arch on my chromebook with crouton.
# 16:21:35 mingwandroid but I lost it now actually.
# 16:22:04 bhundven I wonder if you can port haiku to chromebook...
# 16:22:06 bhundven :D
# 16:22:25 bhundven I have the acer CB3-111
# 16:23:55 mingwandroid I have the 2nd samsung one: http://www.samsung.com/us/computer/chrome-os-devices/XE303C12-A01US
# 16:24:09 Triskelios I have a chromebook 11 for everyday use, and the work laptop I'm on (a thinkpad) also runs chromium os
# 16:24:51 mingwandroid this looks good: http://www.samsung.com/us/computer/chrome-os-devices/XE503C12-K01US
# 16:25:02 bhundven http://us.acer.com/ac/en/US/content/model/NX.MQNAA.001
# 16:25:06 mingwandroid octa-core.
# 16:25:27 bhundven mingwandroid: nice!
# 16:25:50 mingwandroid I have absolutely no need for it, but I'm still tempted.
# 16:25:57 Triskelios yay, finally another one with an IPS screen
# 16:26:44 mingwandroid so bhundven, why is GCC done in 3 passes atm?
# 16:26:58 mingwandroid bhundven: is it just in-case of canadian?
# 16:27:59 bhundven mingwandroid: it was an older requirement of creating the libc.so before the 2nd pass, so the first pass was to make a minimal gcc that was just for making the empty libc.so
# 16:28:30 mingwandroid urgh, an empty libc.so could be made by binutils though I expect?
# 16:28:30 bhundven mingwandroid: so that gcc would have the right paths for things. But, iirc, that was fixed in 4.6 or 4.7
# 16:28:44 mingwandroid ok, yeah, paths ..
# 16:29:27 mingwandroid and multilib flags and paths too. do you want me to try to investigate removing that?
# 16:29:35 mingwandroid and will it still be needed for CCC?
# 16:29:48 bhundven https://github.com/crosstool-ng/crosstool-ng/blob/master/scripts/build/libc/glibc.sh#L427
# 16:30:18 bhundven mingwandroid: I don't think 3-pass is needed for clang
# 16:30:35 bhundven it's mostly an old glibc thing
# 16:30:47 bhundven well, glibc/gcc
# 16:30:48 bhundven thing
# 16:31:23 bhundven buildroot and musl's musl-cross (https://bitbucket.org/GregorR/musl-cross) do 2-pass
# 16:35:12 mingwandroid pass-1 cc can be used for the empty libc.so just fine I expect?
# 16:35:34 Triskelios as long as it supports the right targets, I don't see why not
# 16:36:04 mingwandroid pass 1 is built with --with-newlib --enable-threads=no
# 16:36:14 mingwandroid --disable-shared too
# 16:37:11 bhundven mingwandroid: right, as I said, pass-1 is only there to make the empty libc.so
# 16:37:57 bhundven the startfiles now, should just be the kernel headers
# 16:38:06 bhundven and hence, probably not called startfiles
# 16:38:30 bhundven s/probably not/probably should not be/
# 16:41:24 mingwandroid bhundven: ok I will try removing pass 1, so pass 2 becomes pass 1.
# 16:41:37 mingwandroid bhundven: could get akward, naming things like that is a shame :-)
# 16:42:38 Triskelios mingwandroid: by removing pass 1, is that moving or omitting the creation of libc.so?
# 16:44:58 bhundven Triskelios: an example build: https://sourceware.org/glibc/wiki/x32
# 16:45:26 bhundven note that step is not needed.
# 16:45:52 bhundven just two gcc passes
# 16:49:09 mingwandroid Triskelios: I would like to try removing creation of libc.so yeah.
# 16:49:28 mingwandroid mingw-w64 cross is also 2-pass only.
# 16:50:58 mingwandroid seed-tarball?
# 16:51:12 bhundven mingwandroid: hrm?
# 16:51:13 Triskelios I hope that's just an x32-ism
# 16:51:23 Triskelios bhundven: in the instructions on the wiki
# 16:51:31 mingwandroid Download and untar the seed x32 tar ball under the "gcc" directory in the GCC build tree
# 16:52:21 mingwandroid seems to contain prebuilt libgcc and crt stuffs.
# 16:52:41 bhundven mingwandroid: ah, yea, well. that's not a very good example, I just knew that link.
# 16:53:23 mingwandroid heh. ok.
# 16:53:45 mingwandroid well, tonight I will see how I get on with this task.
# 16:53:50 bhundven https://bitbucket.org/GregorR/musl-cross/src is a good example, but uses musl-libc instead of glibc
# 16:53:56 bhundven but the process should be about the same
# 16:54:15 bhundven mingwandroid: cool
# 16:57:55 Triskelios thanks mingwandroid, let us know what happens
# 16:58:01 mingwandroid will do.
# 16:58:31 mingwandroid Triskelios: if you have time to hunt that directory issue down that'd be good, but if not, I'll just add some directory creation again.
# 16:58:57 mingwandroid Triskelios: I don't like adding stuff in crosstool-ng that the build systems should be doing anyway, but yeah, this is very very strange.
# 16:58:57 bhundven Triskelios: mingwandroid: Thanks for taking time to syncing up!
# 16:59:05 bhundven s/syncing/sync/
# 17:00:11 mingwandroid np.
# 17:00:15 bhundven I'm always on irc (thanks irccloud.com) but I may not always be available.
# 17:00:18 mingwandroid Triskelios: what TZ are you in?
# 17:01:01 Triskelios on work travel to the office this week so EST
# 17:01:12 Triskelios usually remote in CST
# 17:01:45 mingwandroid ok, I'm GMT.
# 17:02:25 bhundven << PST/PDT
# 17:04:42 mingwandroid ok cool. I usually can't get away with IRC until after work which would be in an hour or two from now.
# 17:05:05 bhundven mingwandroid: hey! get back to work!
# 17:05:06 bhundven :D
# 17:05:07 Triskelios I'll stay on although I'm pretty bad at checking alerts
# 17:05:27 bhundven eats his own words ;)
# 17:05:36 mingwandroid ok boss!
# 17:05:42 bhundven lol
# 17:13:52 bhundven mingwandroid: btw, looks like sabotage is using musl-libc with llvm3.4... seems interesting, wrt llvm/clang support in ct-ng: https://github.com/sabotage-linux/sabotage/blob/master/KEEP/llvm34.patch
# 17:15:46 bhundven found that from: https://github.com/armcc/meta-musl/commit/e9bde13e480948a83c747abfb9be6c5856e01c2f
# 17:24:17 enunes joins #crosstool-ng
# 17:34:19 mingwandroid I'll look into that.
# 17:59:46 enunes quits : Read error: Connection reset by peer
# 18:05:12 enunes joins #crosstool-ng
# 18:05:56 mingwandroid_ joins #crosstool-ng
# 18:08:31 mingwandroid quits : Ping timeout: 244 seconds
# 21:02:13 nandub joins #crosstool-ng
# 23:13:47 mingwandroid_ quits : Read error: Connection reset by peer