ibotlog2html for #crosstool-ng

<< Previous 2014-07-27 Next >>

# 00:14:43 bhundven eh, 2 month old seagate drive, starting to fail
# 00:14:44 bhundven http://www.newegg.com/Product/Product.aspx?Item=N82E16822178340
# 00:14:45 bhundven :(
# 00:15:49 memfrob that sucks bro..
# 00:16:03 memfrob oh its a solid state thats wy
# 00:16:18 memfrob they're unreliable as shit
# 00:16:28 bhundven hybrid
# 00:16:39 bhundven it's actually the spindle thats failing
# 00:16:45 bhundven I can hear it clicking
# 00:16:56 memfrob hybrid? the hell..
# 00:16:58 bhundven I've yet to have a problem with any of my solid state drives
# 00:17:29 memfrob it has a flash chip and a wafer in it?
# 00:17:37 bhundven the ssd is only 8G
# 00:17:46 bhundven but you don't see that when you use it
# 00:18:05 bhundven it acts as a read/write staging area for the spindle
# 00:18:07 memfrob so its an 8GB flash drive with wafers in it that attach over SATA?
# 00:18:52 memfrob how do you know what is saved to flash or wafer? or is the flash the cache / buffer for the wafer?
# 00:19:15 bhundven the later
# 00:19:37 bhundven s/later/latter/
# 00:19:53 memfrob but if its an 8GB flash thats used for cache, why doesnt it say 8GB cache as opposed to 64MB?
# 00:20:10 memfrob 64MB cache on the wafers themselves, but a secret 8GB they dont advertise?
# 00:20:21 memfrob (keyword: hybrid) ?
# 00:20:52 bhundven I'm no expert in that stuff.
# 00:21:01 bhundven Reading will get you further then asking me ;)
# 00:21:15 bhundven I just know I have 1TB drive that's failing
# 00:21:52 memfrob warranty..?
# 00:22:03 bhundven yea, if I can find it
# 00:22:20 memfrob did you ever zero it? defrag it? do any of the things that people say not to do?
# 00:22:35 memfrob i wonder if swap can kill an SSD...
# 00:22:44 bhundven wtf is a defrag? is that something you have to manually do on windows?
# 00:22:48 memfrob or filesystems such as fuse or btrfs
# 00:23:01 memfrob well by defrag i meant fsck
# 00:23:07 bhundven they are different
# 00:23:10 memfrob oh..
# 00:23:53 memfrob well still.. do you use fuse? swap? btrfs? virtual filesystems / partitions such as LVM? im not sure which one of these if not all can hurt SSDs im just asking.
# 00:24:31 bhundven I don't think so. I just don't trust cheap seagate drives. I'm sure their sas stuff is better
# 00:24:36 bhundven it was only $99
# 00:25:10 memfrob ever use ZFS? maybe that kills SSDs..
# 00:25:33 bhundven no
# 00:25:35 bhundven ext4
# 00:25:47 bhundven again, I don't think how I use the drive matters
# 00:26:08 memfrob well i know for a fact the windows defrag is a definite no no. so is dding the entire drive.
# 00:26:18 bhundven that is not true.
# 00:26:49 bhundven I can't speak for windows. I haven't used it since 95'
# 00:27:32 bhundven making an image of hard drives is only bad if you don't know what your're doing
# 00:27:39 bhundven s/your're/you're/
# 00:27:46 memfrob i meant dding all zeros to the drive.
# 00:27:57 memfrob and writing /dev/random to the entire drive
# 00:28:09 memfrob i read it puts a lot of stress on it.
# 00:28:23 bhundven key part: "is only bad if you don't know what you're doing"
# 00:30:32 memfrob ah
# 00:35:02 memfrob well.. back when your drive wasnt failing, how much faster was it compared to a normal HDD?
# 00:42:36 bhundven much
# 00:43:10 bhundven sshd + ccache == ffffffaaaaasssstttt
# 00:43:24 bhundven I'm sure just ssd would be nice, but isn't 1TB
# 01:05:55 bhundven https://sourceware.org/ml/crossgcc/2014-07/msg00031.html
# 02:38:16 djerome quits : Remote host closed the connection
# 03:00:09 feep joins #crosstool-ng
# 03:04:39 feep_ joins #crosstool-ng
# 03:06:18 feepbot quits : Ping timeout: 255 seconds
# 03:06:22 feep quits : Ping timeout: 240 seconds
# 03:07:15 feepbot joins #crosstool-ng
# 03:24:27 feep_ is now known as: feep
# 03:28:42 voltagex joins #crosstool-ng
# 03:29:59 voltagex hi, any idea what's causing the following eglibc download error? http://sprunge.us/UZie
# 03:46:23 voltagex got it, broken symlinks
# 04:07:33 voltagex now I can't build because make 4.0 is apparently too old - These critical programs are missing or too old: make
# 08:26:18 kos_tom seems weird, make 4.0 is the latest version.
# 08:28:45 bhundven kos_tom: do you think the experimental patch support is useful for uclibc at all?
# 08:33:08 bhundven I have one more patch to send that uses the description of the experimental patch as the kconfig help, and the name of the patch as CT__EXPPATCH_ to enable applying it or not, instead of the 'all or nothing' approach the current patch set sent to the ml does.
# 08:35:37 bhundven I'm thinking I'll have to add parsing for '^##' for 'depends on ', 'selects ' and others in the patch description.
# 08:45:35 daggs1-work joins #crosstool-ng
# 08:45:56 daggs1-work greetings, does ct-ng supports musl libc?
# 10:02:21 y_morin joins #crosstool-ng
# 10:05:56 daggs1-work y_morin, greetings, whats up?
# 10:06:06 y_morin daggs1-work: Hello!
# 10:06:11 daggs1-work how are you?
# 10:06:25 y_morin daggs1-work: fine! And you?
# 10:06:41 daggs1-work I'm good, say does ct-ng supports musl?
# 10:08:03 y_morin daggs1-work: It should have experimental support some time in the "near" future. See the latest posts on the mailing list.
# 10:08:38 daggs1-work yeah, I'm trying to use these patches but the fail :(
# 10:09:09 y_morin daggs1-work: The ones posted a few hours ago by bhundven ?
# 10:09:39 daggs1-work yes, thought I'm trying to use it with gcc4.6.0
# 10:10:13 daggs1-work took the missing patch from GregorR's musl-cross as I think the origin of them are from there
# 10:10:52 y_morin daggs1-work: I just woke up minutes ago. I haven't had time to look at them.
# 10:12:58 daggs1-work sure, didn't expected for you see them already. I'll digg into the issue after lunch
# 10:48:56 daggs1-work duh! was missing the experimental patch switch, lets see if ti works
# 11:00:58 daggs1-work y_morin, how it is decided what to install buildtools/*/include?
# 11:20:35 daggs1-work funny these patches doesn't compile against 4.8.1 even...
# 12:50:48 daggs1-work y_morin, found the bug in the patches afai can see, musl install installs the files to sysroot/usr/musl/include and in gcc we include only sysroot/usr/include. do we install the headers of glibc to sysroot/usr/include?
# 13:09:58 mingwandroid joins #crosstool-ng
# 14:28:37 RushPL quits : Ping timeout: 245 seconds
# 14:30:25 RushPL joins #crosstool-ng
# 14:57:56 diorcety joins #crosstool-ng
# 16:00:27 diorcety quits : Ping timeout: 240 seconds
# 16:05:55 diorcety joins #crosstool-ng
# 16:27:32 diorcety quits : Ping timeout: 260 seconds
# 17:06:31 diorcety joins #crosstool-ng
# 17:40:50 djerome joins #crosstool-ng
# 18:20:17 diorcety quits : Read error: Connection reset by peer
# 18:22:22 diorcety joins #crosstool-ng
# 18:29:27 diorcety quits : Ping timeout: 240 seconds
# 18:36:40 diorcety joins #crosstool-ng
# 18:40:35 diorcety1 joins #crosstool-ng
# 18:41:46 diorcety2 joins #crosstool-ng
# 18:44:13 diorcety quits : Ping timeout: 255 seconds
# 18:45:00 diorcety1 quits : Ping timeout: 255 seconds
# 18:47:33 feep_ joins #crosstool-ng
# 18:48:06 feep quits : Ping timeout: 250 seconds
# 18:48:12 diorcety2 quits : Ping timeout: 250 seconds
# 18:48:30 diorcety joins #crosstool-ng
# 18:48:35 feepbot quits : Ping timeout: 264 seconds
# 18:49:16 feepbot joins #crosstool-ng
# 18:58:02 diorcety1 joins #crosstool-ng
# 18:59:22 diorcety quits : Ping timeout: 245 seconds
# 19:10:25 diorcety joins #crosstool-ng
# 19:11:52 diorcety1 quits : Ping timeout: 245 seconds
# 19:12:20 sh4rm4 joins #crosstool-ng
# 19:31:33 bhundven Hey daggs1-work!
# 19:49:32 bhundven daggs1-work: when you have a moment, could you post the .config and build log?
# 19:50:47 bhundven I only tested that patch with arm-unknown-linux-muslgnueabi with gcc-4.9.0, and I got the patches directly from musl-cross (as noted in the patch descriptions)
# 19:51:08 bhundven I'll post the sample as well
# 19:51:18 daggs1-work bhundven, greetings, I've created too patches that got me quite far, it fails on mudflup and ltrace but I've disabled them.
# 19:51:23 bhundven but if there is a problem in the patch, I can update that.
# 19:52:10 bhundven there are other patches that musl-cross adds, and I'm looking through them.
# 19:52:40 bhundven I know they have some changes for elfutils and others.
# 19:52:59 bhundven probably dorking up some debug utilities
# 19:53:01 daggs1-work bhundven, there: http://pastebin.com/SZiUPCXp
# 19:53:16 daggs1-work elfutils passed compilation without any issues
# 19:53:51 bhundven doesn't mean it works correctly. ;)
# 19:54:17 daggs1-work I'm compiling gcc-4.6.0 against it so I took the 4.6.3 patch from gregor's repo and used it for 4.6.0 (simple rename)
# 19:54:25 daggs1-work that is correct
# 19:54:46 daggs1-work I'm trying to get a cc build to satisfy my boss
# 19:54:57 bhundven sure
# 19:57:02 bhundven y_morin: would it make sense to add a git submodule that clones/pulls if CT_EXPERIMENTAL_PATCHES from a repository on bitbucket.org/crosstool-ng/experimental-patches ?
# 19:57:29 daggs1-work bhundven, config: http://pastebin.com/Qxduzxm4
# 19:57:35 bhundven y_morin: then we aren't thrashing in your git repository
# 19:59:01 voltagex1 joins #crosstool-ng
# 20:00:22 bhundven daggs1-work: thanks for the config
# 20:00:25 bhundven !
# 20:01:02 daggs1-work np
# 20:01:39 bhundven daggs1-work: also, just a neat feature tip... in my patch set, you can also add a local experimental patch path. Enable local patches in the paths menu, then set the order to Bundled, Local
# 20:01:49 bhundven what ever directory you point local to
# 20:02:03 daggs1-work probably missed that
# 20:02:08 imMute^ joins #crosstool-ng
# 20:02:15 bhundven also has an: experimental///patch.patch
# 20:02:26 daggs1-work failed on strace :( PTRACE_POKEUSR undefined...
# 20:02:31 daggs1-work did that :)
# 20:02:45 RushPL_ joins #crosstool-ng
# 20:03:04 daggs1-work strange, defs.h complains it is redefined, syscall.c doesn't know it.
# 20:03:17 daggs1-work well, ditching strace foe now
# 20:03:24 bhundven (idk how much the local experimental path makes sense... since if it's in your local path, it's pretty much already experimental)
# 20:04:07 bhundven maybe I'll remove that in the next patch update
# 20:04:18 daggs1-work didn't you encountered issues with the install-headers of musl?
# 20:05:50 bhundven is it a problem when compiling something with the toolchain or a problem during bootstrap?
# 20:06:35 daggs1-work running make install-headers installs the headers to sysroot/usr/local/musl/include
# 20:06:59 bhundven hmm, yup
# 20:07:09 daggs1-work when gcc is complied, he doesn't takes into account that path and fails compilation due to fenv.h missing
# 20:07:34 bhundven but, i have all the same headers plus the linux headers in sysroot/usr/include
# 20:07:46 bhundven and fenv.h
# 20:07:53 daggs1-work depends on the kernel version.
# 20:08:20 daggs1-work I assume, I'm using 2.6.22 which probably doesn't have that file
# 20:08:20 bhundven 3.15.4
# 20:08:44 daggs1-work unfotunatly, I cannot upgrade that kernel.
# 20:09:53 bhundven not questioning your work, just curious what the case is for such an old kernel and older gcc?
# 20:10:56 daggs1-work production compiler, last time we upgraded it, whole hell broke loose in the code, my boss doesn't like such changes
# 20:11:00 RushPL quits : *.net *.split
# 20:11:01 voltagex quits : *.net *.split
# 20:11:05 imMute quits : *.net *.split
# 20:11:07 daggs1-work we still use cvs :-S
# 20:11:17 bhundven heh, been there, done that ;)
# 20:12:36 bhundven they moved to perforce, and I added static toolchain support to ct-ng to get them to change from some old-school dan kegel scripts (which they had one for each platform/architecture) :sigh:
# 20:12:54 bhundven anyways, I feel the pain
# 20:13:01 daggs1-work maybe the right solution for the install headers is to add that path exists
# 20:13:50 daggs1-work git is great, the kernel team are using it... no! just cvs
# 20:14:02 bhundven hehe
# 20:14:12 daggs1-work he asked us at one time to try and compile cvsnt on linux
# 20:15:15 daggs1-work well, I've seems to have a musl based gcc 4.6.0 cross compiler
# 20:26:49 daggs1-work log underway
# 20:27:44 y_morin bhundven, daggs1-work: sorry guys, I stayed out of focus this afternoon... I'm back, now.
# 20:27:59 y_morin bhundven: No problem with having the experimental patches in-tree.
# 20:28:56 bhundven y_morin: ok
# 20:29:15 daggs1-work bhundven, got the log?
# 20:29:42 bhundven yup
# 20:29:47 daggs1-work cool
# 20:31:25 y_morin daggs1-work, bhundven: about the sysroot/usr/include/musl/ sub-dir: we already have another similar case with mingw, which is looking files in sysroot/mingw/ instead of in /usr/include/
# 20:31:40 daggs1-work I'm still not sure that installing the headers to sysroot/usr/local/musl/include is a good idea, this should be a replacement for glibc, I don't see any sysroot/usr/local/libc/include
# 20:31:49 y_morin So, if we can't fix musl to behave properly when installign its headers, we can just symlink.
# 20:31:52 y_morin daggs1-work: Agreed.
# 20:32:04 bhundven so, I don't seem to have a problem there.
# 20:32:14 bhundven as I mentioned
# 20:32:21 daggs1-work y_morin, my fix was to force it to install the headers to sysroot/include
# 20:32:44 bhundven I did have the sysroot/usr/local/musl/include, as well as populated sysroot/usr/include
# 20:32:45 y_morin daggs1-work: ghow did you "force" that?
# 20:33:03 bhundven y_morin: he is using 2.6.22
# 20:33:07 daggs1-work y_morin, brute force the makefile :-P
# 20:33:13 bhundven which doesn't support installing headers
# 20:33:20 bhundven well
# 20:33:43 bhundven not properly, iirc
# 20:33:44 daggs1-work bhundven, it does support (patches the script file)
# 20:33:47 y_morin bhundven: Well, 2.6.22 does have headers-install. Although it was pretty new at the time.
# 20:34:01 daggs1-work thing is, that file never gets installed
# 20:34:18 bhundven daggs1-work: which file?
# 20:34:22 y_morin bhundven: Yep, headers-install only got to work properly aroun 2.6.27, IIRC.
# 20:34:23 daggs1-work s/patches/patched/g
# 20:34:29 daggs1-work fenv.h
# 20:34:32 bhundven right
# 20:34:37 y_morin daggs1-work: fenv.h comes from the C library, not the kernel.
# 20:34:48 bhundven so the include files exist in the right spot for me
# 20:35:08 bhundven because the installer did the right thing because the fenv file exists
# 20:35:34 daggs1-work y_morin, assumed that
# 20:35:45 y_morin bhundven: So, musl must be installing its files depending on the sanity of the installed kernel headers, or some such?
# 20:36:12 bhundven I'm also making an assumption. But I'm working on reproducing his build here so I can figure it out
# 20:36:12 y_morin should have a look at the musl source some day... Why not now?
# 20:36:29 bhundven :)
# 20:36:42 y_morin Oh! I alkready have the git tree cloned here! :-)
# 20:38:30 y_morin bhundven: What kind of threads does musl implements: NPTL of LT ?
# 20:39:21 y_morin sh4rm4: ^^^^
# 20:39:29 daggs1-work crap, the lib is installed to sysroot/usr/lib/libc.so
# 20:39:55 sh4rm4 y_morin, it has the first post-NPTL pthreads impl
# 20:40:00 sh4rm4 i.e. none of both
# 20:40:39 sh4rm4 not sure why you're asking
# 20:40:54 sh4rm4 could probably give a better explanation given more background info
# 20:41:33 y_morin sh4rm4: Well, there are two existing htreads implementations: the legacy (long-dead now) LinuxTHreads, and the new (but not so new) NPTL.
# 20:41:48 sh4rm4 now there are three
# 20:41:56 y_morin sh4rm4: NPTL is a standrads-compliant implementation, and uses facilities from the kernel.
# 20:42:10 sh4rm4 NPTL is not quite conformant, but well
# 20:42:24 y_morin sh4rm4: Yes, right, but it's far better than LT.
# 20:42:24 sh4rm4 musl's is 100% conforming to the spec
# 20:42:38 daggs1-work bhundven, did the lib got installed at sysroot/lib for you?
# 20:42:58 y_morin sh4rm4: OK, but I am wondering what that means, with regards to inclusion in ct-ng...
# 20:43:03 bhundven just starting to build on my pathetic laptop
# 20:43:08 bhundven :D
# 20:43:31 bhundven (not the macbook pro :( )
# 20:43:32 y_morin sh4rm4: Because then, it means we need to handle yet another threads implementation.
# 20:43:35 daggs1-work our production server is 24 cores, 96 gb of ram
# 20:43:42 sh4rm4 y_morin, regarding what ? is there a "general" (i.e. non-libc specific) menu-entry which lets you choose the thread impl ?
# 20:43:54 bhundven daggs1-work: sounds like my old build box at watchguard
# 20:43:59 y_morin sh4rm4: So, I wondered if it could be considered to be sufficiently NPTL-like to consider it NPTL?
# 20:44:14 sh4rm4 in which regard ?
# 20:44:19 y_morin sh4rm4: Yep, depending on the OS and C library combo.
# 20:44:54 sh4rm4 it's a POSIX conformant pthreads impl, so it's not NPTL
# 20:45:07 y_morin sh4rm4: For example: for glibc on Linux: only NPTL is available. For mingw (thus windows), only mingw threads are available. But for uClibc on linux, both LT and NPTL are vailable.
# 20:45:09 sh4rm4 and it's not able to switch it off or on
# 20:45:37 y_morin sh4rm4: OK. I'm just trying to get my head around it.
# 20:45:52 sh4rm4 it's deeply embedded in the whole musl core
# 20:45:59 daggs1-work my makefile patch isn't good for the libs :( will need to redo it.
# 20:46:15 daggs1-work ok, time for bed, night all!
# 20:46:44 y_morin sh4rm4: I am not commenting on whether it should be or should not be possible to disable it! ;-) I'm just trying to find the best fit for the current infra in ct-ng.
# 20:46:49 y_morin daggs1-work: Night! See ya!
# 20:47:11 sh4rm4 y_morin: if you need a name for a menu entry, how about "native"
# 20:47:32 sh4rm4 but then since it can't be disabled is there a point to show a menu entry at all ?
# 20:48:28 y_morin sh4rm4: Yes, because the current infra is generic, and does not depend on the C library. The C library only tells which variant it supports, and the infra builds up the choice. And we need the choice because some libs have a choice.
# 20:48:46 y_morin sh4rm4: But for glibc, for example, the choice is limitted to "NPTL" and nothing else.
# 20:49:15 y_morin (well, that or "none") But it can be valid for a C library to state it does not support "no thread", too.
# 20:50:52 y_morin Hmm. in fact, glibc only support NPTL, not "none".
# 20:51:29 sh4rm4 ok, then make that "musl-native" for musl
# 20:52:22 y_morin sh4rm4: Could you (briefly) explain how the threads implementation in musl differ from NPTL? What are the key points?
# 20:54:29 sh4rm4 i'm not sure there's a reason for gcc to care about that difference
# 20:54:29 sh4rm4 but calling it nptl seems wrong
# 20:54:39 sh4rm4 why isn't it just called posix?
# 20:55:39 bhundven afaik, it is: http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
# 20:56:17 sh4rm4 NPTL is the name the glibc guys gave their new pthreads impl
# 20:56:27 sh4rm4 but its entirely glibc-specific
# 20:56:43 sh4rm4 (and since uclibc copied the code verbatim, it applies there as well)
# 20:56:56 sh4rm4 (but hey, they even #define __GLIBC__)
# 20:57:03 bhundven hehe
# 20:58:24 bhundven now we should support dietlibc :P (jk)
# 20:58:36 y_morin sh4rm4: OK, thanks! :-)
# 20:59:14 y_morin bhundven: So, what about merging the "musl" and "NPTL" flags into a single flag "native (NPTL/musl/...)" ?
# 20:59:25 bhundven fine by me
# 20:59:37 bhundven to thread, or not to thread... that is the question.
# 21:00:05 y_morin bhundven: The differentiation was especially due to the LT / NPTL difference. But musl is native threads, like NPTL.
# 21:00:10 y_morin bhundven: :-p
# 21:00:47 bhundven maybe a modifier for glibc, if LT is set, then it uses that instead (for older toolchains?)
# 21:01:03 bhundven but that would be specific to (e)glibc
# 21:01:06 y_morin bhundven: glibc has no LT implementation any more!
# 21:01:13 y_morin bhundven: It's uClibc that has.
# 21:01:17 bhundven ah
# 21:01:24 bhundven well same case, different package
# 21:01:29 y_morin bhundven: Yep.
# 21:01:51 bhundven then uclibc is the only one that is "different"
# 21:02:06 y_morin bhundven: Not really, because we also have ming threads.
# 21:02:14 bhundven everyone else has: threads=
# 21:02:50 y_morin *mingw
# 21:02:52 bhundven sure
# 21:05:14 bhundven {uclibc,mingw}=each different; everyone else has: threads=
# 21:05:29 bhundven :)
# 21:06:55 y_morin bhundven: not really. {glibc,mingw} -> can only use threads (resp. NPTL, win32); {uClibc} -> can use {none,LT,NPTL}
# 21:12:10 bhundven nods, shakes his head, leaves threading to y_morin . :)
# 21:21:30 bhundven I'm out for a while. bbl
# 21:26:07 djerome quits : Remote host closed the connection
# 21:53:40 diorcety quits : Ping timeout: 255 seconds
# 22:21:32 y_morin bhundven: Ping? Are you around?
# 22:29:17 y_morin bhundven: Here's a rewrite of the thread stuff: http://ymorin.is-a-geek.org/git/crosstool-ng/ in branch yem/threads-rework
# 22:30:29 y_morin bhundven: It should help with adding the musl "native" threads implementation, hopefully. If not, just yell! ;-)
# 22:54:58 sh4rm4 So, if we can't fix musl to behave properly when installign its headers, we can just symlink.
# 22:55:07 sh4rm4 what's the problem here ?
# 22:56:54 sh4rm4 the headers should go into sysroot/usr/include
# 22:57:24 y_morin sh4rm4: daggs1-work reported having headers isntalled in sysroot/usr/local/musl/include instead of the expected sysroot/usr/include
# 22:57:34 sh4rm4 so you would configure musl like --prefix=/usr
# 22:57:45 sh4rm4 and make DESTDIR=$sysroot install
# 22:58:15 sh4rm4 y_morin, oh; in that case configure was either not called
# 22:58:16 y_morin sh4rm4: Yep, that's what the patch provided by bhundven does
# 22:58:28 sh4rm4 or an out-of-tree build was started
# 22:58:33 sh4rm4 so config.mak was not found
# 22:58:35 y_morin sh4rm4: Too slow at answering.
# 22:58:47 sh4rm4 hm?
# 22:58:51 y_morin sh4rm4: I meant: bhundven's patch does --prefix=/usr
# 22:59:22 y_morin sh4rm4: and it does no out-of-tree build
# 23:00:53 y_morin sh4rm4: Ah! I think I know the reason, now (I'm just reviewing his patch right now): it builds the headers without calling ./configure first...
# 23:01:08 sh4rm4 ah
# 23:01:20 sh4rm4 why would it install the headers first tho ?
# 23:01:37 y_morin sh4rm4: So, basically, it does: make install-headers DESTDIR=sysroot; ./configure --prefix=/usr; make; make install DESTDIR=sysroot
# 23:01:53 y_morin sh4rm4: that's the standard steps in ct-ng.
# 23:02:03 sh4rm4 not needed for musl
# 23:02:37 y_morin sh4rm4: You mean we can do: bootstrap-gcc; musl; final-gcc ?
# 23:02:48 sh4rm4 yes
# 23:03:11 y_morin sh4rm4: And boostrap-gcc does not need the headers from usl?
# 23:03:16 sh4rm4 no
# 23:03:16 y_morin *musl
# 23:04:01 y_morin sh4rm4: Interesting... Other C libraries require at leastr: libc-headers; bootstrap-gcc; full-libc; final-gcc
# 23:04:08 y_morin *least
# 23:05:05 sh4rm4 yeah, i dont know the reason though
# 23:05:13 y_morin And NPTL requires even more: boostrap-gcc-1; libc-start-files; bootstrap-gcc-2; full-libc; final-gcc
# 23:06:09 sh4rm4 it's probably due to some quirks in the glibc headers
# 23:07:47 sh4rm4 i'm actually unsure why the second gcc is needed at all
# 23:08:46 y_morin sh4rm4: That is because there is some intricacy between gcc and glibc, whereby gcc needs a libc.so and a few other files to build its own internal libs (libgcc_s.so, for example?)
# 23:09:04 y_morin Even though an empty libc.so works perfectly.
# 23:09:10 sh4rm4 ah
# 23:09:21 y_morin sh4rm4: IIRC, the latest gcc versions fixed that dependency.
# 23:09:28 sh4rm4 that's probably why the first gcc is built with --disabled-shared
# 23:09:34 sh4rm4 in musl-cross
# 23:09:46 y_morin sh4rm4: Yep, we do that in ct-ng, too.
# 23:10:41 sh4rm4 however --disable-shared causes some subtle breakage...
# 23:10:57 sh4rm4 it leads to libgcc symbols not being hidden as they should
# 23:11:25 sh4rm4 which has the result that when libc.so is built against libgcc.a, those symbols get pulled into libc.so and exported
# 23:11:48 y_morin sh4rm4: Yep. But in ct-ng, since we do a three-pass gcc, we do not have the issue, since we use libgcc_s from the second gcc, whioch is built with --enable-shared.
# 23:11:57 sh4rm4 https://gist.github.com/rofl0r/9249533
# 23:25:37 bhundven just to explain again
# 23:26:03 bhundven in my tests, musl-libc headers are installed to the correct place in sysroot/usr/include
# 23:26:18 bhundven but are *also* installed to sysroot/usr/local/musl/include
# 23:26:49 sh4rm4 why?
# 23:26:58 bhundven there is some problem I am trying to debug with daggs1-work's config, because he is using an older kernel, before headers-install was working properly (2.6.22
# 23:26:58 bhundven )
# 23:27:07 bhundven my guess
# 23:27:18 y_morin bhundven: I think I know why: since do_libc_start_files() does not call do_libc_configure, it installs files in /usr/local/musl/include
# 23:27:32 sh4rm4 kernel headers are utterly broken anyway
# 23:27:35 bhundven right, so I have a bug there
# 23:27:37 bhundven y_morin: ^^
# 23:27:46 y_morin bhundven: But then, in do_libc(), you call do_libc_configure, and that would install them in the correct place.
# 23:27:57 bhundven right
# 23:28:12 bhundven I think that is the problem, because his build fails before libc is built
# 23:28:45 bhundven so let me revise, including thread fixes
# 23:29:17 y_morin bhundven: Did you have a look at the few patches I added to my branch? Will that help you?
# 23:29:27 bhundven just sat down
# 23:29:40 y_morin bhundven: OK! ;-)
# 23:30:05 y_morin bhundven: If they are OK for you, just carry them in your branch.
# 23:30:25 y_morin bhundven: You just sat down. I will sonn lie down (1:30am here)
# 23:31:17 bhundven sure!
# 23:31:27 bhundven 4:30pm here
# 23:32:27 bhundven oh, you applied the experimental patch
# 23:32:31 sh4rm4 quits : Ping timeout: 256 seconds
# 23:32:33 bhundven hehe
# 23:32:45 y_morin bhundven: Well, it is what we said it should be, so why not?
# 23:32:57 bhundven I was just about to send you a different version, that did not include local_exp
# 23:33:18 bhundven doesn't really make much since, since your local path is already experimental
# 23:33:56 y_morin bhundven: Well, I was a bit unsure about it. But I can see the point of having stable local patches, and experimental ones, especially if they are shared across different developpers.
# 23:34:07 bhundven fair enough
# 23:34:18 y_morin bhundven: And it's simple enough to handle, so...
# 23:34:43 bhundven go sleep. I'll have more patches for you in the morning :)
# 23:34:50 y_morin Anyway, I'm off.
# 23:34:55 y_morin ;-)
# 23:34:58 y_morin See you guys!
# 23:35:03 bhundven l8r y_morin
# 23:35:07 y_morin quits : Quit: Nighty Night!

Generated by ibotlog2html by Yann E. MORIN