| # 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! |