# 05:32:39 |
mnt_real |
quits : Quit: Leaving |
# 07:35:04 |
y_morin |
joins #crosstool-ng |
# 07:40:36 |
smartin |
joins #crosstool-ng |
# 08:45:40 |
sinseman44 |
quits : Quit: leaving |
# 09:11:56 |
y_morin |
quits : Ping timeout: 252 seconds |
# 09:23:27 |
y_morin |
joins #crosstool-ng |
# 11:04:43 |
esbenh |
joins #crosstool-ng |
# 11:05:08 |
esbenh |
#!)(/#()/!"/! glibc release engineering |
# 11:05:30 |
esbenh |
why on earth cannot they manage to tar up the glibc-ports release when tagged? |
# 11:05:42 |
esbenh |
how hard can it be :-( |
# 11:06:20 |
esbenh |
I am now trying to trick ct-NG into using it from git instead, but is running into some issues |
# 11:11:22 |
y_morin |
esbenh: Hello! I'll put the tarball on the crosstool-ng.org server |
# 11:18:14 |
y_morin |
esbenh: You can go to: Paths and misc options ---> [*] Use a mirror and then set: (http://crosstool-ng.org/mirrors/) Base URL |
# 11:19:01 |
y_morin |
esbenh: that tarball for ports was made around july the 3rd, 2011. |
# 11:21:07 |
esbenh |
yes, but that won't really help me |
# 11:21:33 |
esbenh |
I have just changed the OE-lite integration of ct-NG, to always use CT_FORBID_DOWNLOAD, and then let the OE-lite fetcher do the fetching |
# 11:21:57 |
esbenh |
this is needed for me to properly handle source signatures for ct-NG builds |
# 11:24:01 |
y_morin |
esbenh: Ah... |
# 11:24:44 |
esbenh |
so I fetch the glibc-ports.git repo and checks it out at glibc-2.14 tag |
# 11:24:53 |
esbenh |
so far, so good. |
# 11:25:22 |
esbenh |
but do_libc_extract does not take that to well |
# 11:28:02 |
esbenh |
I am now trying to figure out why the ports is not properly moved to glibc-2.14/ports |
# 11:28:12 |
esbenh |
which is done when it is fetched as tarball |
# 11:30:25 |
y_morin |
esbenh: How did you create the ports tarball ? |
# 11:30:54 |
esbenh |
I don't have a tarball |
# 11:31:13 |
esbenh |
I just have glibc-ports-2.14/.git |
# 11:31:34 |
esbenh |
which CT_Extract finds, and does a CT_ExtractGit with |
# 11:32:22 |
y_morin |
esbenh: Oh, that has never, ever been tested so far! :-( |
# 11:32:55 |
y_morin |
esbenh: it was a tentative on my part to try to use git instead of tarballs, but I never finished that... :-( |
# 11:33:26 |
y_morin |
esbenh: it dates back... a long time ago... |
# 11:34:00 |
esbenh |
I sort of sensed that :-) |
# 11:34:14 |
esbenh |
newer the less, I want to get it working now :-) |
# 11:34:41 |
y_morin |
esbenh: Ah, that's nice. |
# 11:40:16 |
esbenh |
seems like the only permanent solution to working wiht glibc releases |
# 11:56:48 |
esbenh |
y_morin: so CT_ExtractGit is not to be considered used in any context currently? |
# 11:57:04 |
esbenh |
y_morin: I might want to change the API slightly... |
# 11:57:08 |
y_morin |
esbenh: indeed, there's no official caller so far. |
# 11:57:16 |
y_morin |
esbenh: go on! ;-) |
# 11:58:40 |
esbenh |
thanks :-) |
# 12:00:32 |
esbenh |
hmm... might not even be needed :-) |
# 12:41:11 |
esbenh |
I think I have a working pathc |
# 12:41:13 |
esbenh |
patch even |
# 12:41:21 |
esbenh |
need to figure out the hg diff thingy |
# 12:41:52 |
esbenh |
I still miss installing git-fu in my brain |
# 12:43:22 |
y_morin |
esbenh: hg commit (babla); hg email --outgoing --to crossgcc@... |
# 12:51:29 |
esbenh |
I guess the hg email command requires a working email setup of some kind. |
# 12:58:12 |
esbenh |
does hg has a command-line helper for add sob's? |
# 13:14:07 |
y_morin |
esbenh: there is no provision for the SoB thingies in Hg. I have a hook for MQ that appends one on new MQ patches, but that requires use of MQ. |
# 13:14:16 |
y_morin |
esbenh: and for the email setup: hg help email. |
# 13:16:05 |
esbenh |
well, I have never figured out how to handle this )(/¤#)(!/! Exchange server at work, so I cannot send email from Linux like that :-( |
# 13:16:19 |
esbenh |
and port 25 is "of-course" blocked :-( |
# 13:16:59 |
esbenh |
anyway, it seems like it actually went through |
# 13:17:03 |
esbenh |
forgot the sob line though. |
# 13:23:01 |
y_morin |
esbenh: just saw the mail, so yes, it went through. Just reply to the mail on the list with your SoB line, i'll add it locally before the final push. |
# 13:23:24 |
y_morin |
esbenh: I'll handle that tonight, when back at home... |
# 13:23:25 |
y_morin |
esbenh: thank you! :-) |
# 13:25:45 |
esbenh |
np |
# 13:26:24 |
esbenh |
already did so, but it first tried to get out through one fo my (now) broken mailservers |
# 13:27:18 |
esbenh |
are you (or someone else) working on a method for dumping the list of sources to be downloaded? |
# 13:27:55 |
esbenh |
I would like to add a QA step in OE-lite, comparing the list of sources I am providing to ct-NG, with what ct-NG needs. |
# 13:28:07 |
y_morin |
esbenh: you're not the first to ask... There is already this need for buildroot to use such a feature in crosstool-NG, but no code so far... |
# 13:28:27 |
y_morin |
esbenh: it is not currently possible with the way crosstool-NG handles downloads... |
# 13:28:32 |
esbenh |
I get proper failure when missing sources (thanks for CT_FORBID_DOWNLOAD!), but I would like to have a way for printing a warning if to many sources were provided. |
# 13:28:53 |
esbenh |
it is not in any way critical for me |
# 13:29:00 |
esbenh |
just a nice-to-have feature |
# 13:29:40 |
y_morin |
esbenh: I have a few ideas I'd like to ponder, on the way we handle downloads. So far, it's not even totally clear in my head... |
# 13:31:30 |
y_morin |
esbenh: basically, I'd like to review completely the way crosstool-NG handles dependencies (such as: "building foo" require "building bar", but also: "building foo" requires "downloading foo" and "extracting foo") |
# 13:32:26 |
y_morin |
esbenh: currently, these are completely handled by conditionals and sequences, but that not scalable in the long term... |
# 13:33:52 |
y_morin |
So, instead of using a single script with conditionals, I'd like to move to a Makefile with proper dependencies, eg: ifeq ($(BLA),y) / gcc_deps+=gmp / endif; and add $(gcc_deps) as pre-requisites to the gcc rule. |
# 13:44:00 |
smartin |
quits : Ping timeout: 252 seconds |
# 14:11:02 |
esbenh |
y_morin: hehe, I think I should really present you how OE-lite works at ELCE ;-) |
# 14:14:53 |
y_morin |
esbenh: I'll be there! ;-) |
# 14:31:02 |
esbenh |
I booked my return to saturday afternoon, so I will be at the workshop also |
# 14:34:27 |
y_morin |
esbenh: you mean, the crosstool-NG workshop on staurday? Great! :-) |
# 16:07:22 |
y_morin |
quits : Ping timeout: 252 seconds |
# 17:22:20 |
y_morin |
joins #crosstool-ng |
# 17:54:33 |
y_morin |
is now known as: y_morin|away |
# 18:04:23 |
y_morin|away |
is now known as: y_morin |
# 18:23:33 |
y_morin |
is now known as: y_morin|away |
# 18:45:52 |
KAeL |
quits : Quit: Changing server |
# 18:58:58 |
kpet |
joins #crosstool-ng |
# 19:25:26 |
josec |
joins #crosstool-ng |
# 19:25:44 |
josec |
quits : Client Quit |
# 19:30:09 |
smartin |
joins #crosstool-ng |
# 19:38:59 |
y_morin|away |
is now known as: y_morin |
# 19:59:50 |
smartin |
quits : Ping timeout: 252 seconds |
# 20:36:55 |
mnt_real |
joins #crosstool-ng |
# 21:40:24 |
sh4rm4 |
sigh, the gcc build system is so fucked up |
# 21:40:44 |
sh4rm4 |
i'm thinking about creating a "makefiles-for-gcc" project |
# 21:41:29 |
sh4rm4 |
analyes what gcc builds in which order, and add a single makefile that does the same (if it even makes sense) |
# 21:42:21 |
sh4rm4 |
that'd probably cut compilation time in half, and reduce build errors to near zero |
# 21:43:11 |
y_morin |
sh4rm4: but that would not be portable/reaptable/... |
# 21:43:22 |
y_morin |
*repeatable |
# 21:43:26 |
sh4rm4 |
why not ? |
# 21:43:52 |
sh4rm4 |
i wouldn't care really if it builds for IRIX 0.07 |
# 21:44:03 |
y_morin |
I mean, I would not be able to use your Makefile on my machine, it's not necessarily the same libs, the same versions, the same paths... |
# 21:44:21 |
sh4rm4 |
it should just compile on a posix compliant system without further ado.. |
# 21:44:41 |
sh4rm4 |
well, you want to customize which path's it uses, of course |
# 21:45:18 |
y_morin |
sh4rm4: but you'd need a few variants, at least: one with cloog+ppl for GRAPHITE, one with libelf for LTO, but only for gcc-4.5, and so on... |
# 21:45:26 |
sh4rm4 |
and for cross compilation, build stuff that like xgen or how it is called with $HOSTCC |
# 21:46:12 |
sh4rm4 |
y_morin, the Makfile would be accompanied by a config.mak, where you can just enable/disable those options by putting a # |
# 21:47:23 |
y_morin |
sh4rm4: but what about those systems where libcloog would be in /usr/lib, and another in /usr/local/lib, or in a place ld does not know about? |
# 21:47:39 |
y_morin |
./configure is here just to solve those issues... |
# 21:47:44 |
sh4rm4 |
you'd just pass -L in CFLAGS |
# 21:47:52 |
y_morin |
is now known as: y_morin|away |
# 21:47:56 |
y_morin|away |
is now known as: y_morin |
# 21:48:05 |
y_morin |
Woops.. Bad key-combo... |
# 21:48:10 |
sh4rm4 |
heh |
# 21:48:50 |
y_morin |
sh4rm4: So you'd want to replace ./configure? ;-) |
# 21:49:02 |
sh4rm4 |
remove it, yes |
# 21:49:22 |
sh4rm4 |
because it really is just a waste of time and epic failure |
# 21:49:43 |
sh4rm4 |
testing size of uint8_t ... 1 |
# 21:49:48 |
sh4rm4 |
how amazing. |
# 21:50:04 |
y_morin |
sh4rm4: I can't agree more on the "waste of time", and no less on the "epic failure" part! :-) |
# 21:50:38 |
y_morin |
sh4rm4: yep, autocrap was not conceived with cros-compilation in mind. |
# 21:51:41 |
sh4rm4 |
it looks as if they had not much in mind at all... maybe except creating somthing so huge and complex that they can keep their jobs because nobody else understands the build system |
# 21:52:06 |
y_morin |
sh4rm4: don't make me laugh, please! :-) |
# 21:52:30 |
sh4rm4 |
;) |
# 21:56:51 |
ccct |
http://code.google.com/p/quagmire/ |
# 21:57:03 |
ccct |
tromey (one of autotools authors) tried to replace it many years ago |
# 21:57:16 |
ccct |
http://tromey.com/blog/?p=394 |
# 22:00:25 |
y_morin |
ccct: interesting. Thx. |
# 22:02:03 |
sh4rm4 |
unfortunately dead |
# 22:02:15 |
y_morin |
yep... :-( |
# 22:03:59 |
y_morin |
quits : Quit: Night is for sleeping... |