# 03:10:27 |
drasko_ |
quits : Quit: Ex-Chat |
# 03:33:26 |
perr |
joins #crosstool-ng |
# 04:33:05 |
perr |
quits : Ping timeout: 246 seconds |
# 04:51:43 |
perr |
joins #crosstool-ng |
# 05:04:58 |
perr |
quits : Ping timeout: 260 seconds |
# 05:19:47 |
perr |
joins #crosstool-ng |
# 06:05:49 |
memleak |
quits : Ping timeout: 272 seconds |
# 06:17:14 |
memleak |
joins #crosstool-ng |
# 07:12:24 |
smartin_ |
joins #crosstool-ng |
# 07:31:17 |
bhundven |
hmm, crosstool-ng.org down again? |
# 07:33:50 |
bhundven |
yup. |
# 09:34:21 |
perr |
quits : Ping timeout: 245 seconds |
# 09:34:53 |
perr |
joins #crosstool-ng |
# 09:38:45 |
y_morin |
joins #crosstool-ng |
# 09:59:11 |
perr |
quits : Ping timeout: 265 seconds |
# 10:14:52 |
perr |
joins #crosstool-ng |
# 11:06:39 |
perr |
quits : Read error: Connection reset by peer |
# 13:21:04 |
y_morin |
bhundven: Hello? |
# 13:21:16 |
y_morin |
bhundven: crosstool-ng.org is up for me. |
# 13:22:04 |
y_morin |
bhundven: Ah.. We have yet another SYN_RECV offender... |
# 13:30:16 |
perr |
joins #crosstool-ng |
# 13:34:29 |
perr |
quits : Ping timeout: 248 seconds |
# 13:46:44 |
perr |
joins #crosstool-ng |
# 14:12:14 |
mingwandroid |
joins #crosstool-ng |
# 14:13:29 |
perr |
quits : Ping timeout: 272 seconds |
# 14:34:54 |
mingwandroid |
ping |
# 14:35:18 |
mingwandroid |
y_morin: I want to kick off the biggest multilib test I can .. |
# 14:35:37 |
mingwandroid |
y_morin: arm is the best candidate I guess: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083/enable-with-multilib-list-for-arm.patch |
# 14:36:08 |
y_morin |
mingwandroid: ARM has has probably the largest multilib combinations I can think of... |
# 14:36:54 |
mingwandroid |
y_morin: seems that there's a --with-multilib-list config option |
# 14:37:53 |
y_morin |
mingwandroid: IIRC, if you don't specify it, it takes the default value |
# 14:38:14 |
y_morin |
mingwandroid: ... which is to build all variants known to gcc. |
# 14:38:16 |
mingwandroid |
y_morin: .. "--enable-targets=all" ? |
# 14:38:42 |
y_morin |
mingwandroid: I don;'t know about --enable-targets. Is that related to multi-arch? |
# 14:40:53 |
mingwandroid |
y_morin: I think it predates multi-arch if you mean that new debian stuff? |
# 14:41:14 |
y_morin |
mingwandroid: Ah, yes, it does. Never used it... |
# 14:41:54 |
mingwandroid |
y_morin: I'm trying to find some useful documentation. I want every variant imaginable from vfp/thumb/neon/32+64bit |
# 14:42:37 |
mingwandroid |
y_morin: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00378.html |
# 14:44:58 |
y_morin |
mingwandroid: well, aarch64 is yet another beast... |
# 14:45:44 |
mingwandroid |
y_morin: I would hope that it's done the same as "-marm, -mthumb, -maarch64"? |
# 14:45:45 |
y_morin |
mingwandroid: I'm a bit confused bwtween that multilib vs. multi-targets (not multi-arch). Seems like it's not orthogonal... |
# 14:46:08 |
y_morin |
mingwandroid: No, aarch64 is not arm; it' is aarch64. |
# 14:46:40 |
y_morin |
At least, as I understand it... |
# 14:46:44 |
mingwandroid |
y_morin: yeah, same as thumb ISA isn't arm ISA, neither is aarch64? |
# 14:47:01 |
mingwandroid |
thumb1 that was, before intermix came along with thumb2 :-) |
# 14:47:05 |
mingwandroid |
it's a mess! |
# 14:47:33 |
mingwandroid |
my understanding of multi-target is that multilib is the library-side of that really.. |
# 14:47:42 |
mingwandroid |
.. could be completely wrong of course. |
# 14:48:32 |
y_morin |
mingwandroid: as I read it, multi-target only makes sense for the 32-bit variant. The 64-bit variant is always capable of genenrating 32-bit code. |
# 14:48:52 |
y_morin |
mingwandroid: But the 32-bit vairaint is not (by default) capable of generating 64-bit code. |
# 14:49:44 |
mingwandroid |
y_morin: I'm going to read up on AArch64 I think. |
# 14:49:46 |
y_morin |
mingwandroid: So, without multi-target, a 32-bit compiler is only a 32-bit compiler. While with multi-target, a 32-bit compiler is both a 32- and 64-bit compiler, defaulting to 32-bit. |
# 14:50:14 |
y_morin |
mingwandroid: While a 64-bit compiler is always a dual 32- and 64-bit compiler, defaulting to 64-bit. |
# 14:50:24 |
y_morin |
That's the way I understand it, at least. |
# 14:50:42 |
mingwandroid |
y_morin: ok, thanks. you're probably right. |
# 14:50:58 |
y_morin |
mingwandroid: And multi-target is only supported for sparc-linux, powerpc-linux, x86-linux, mips-linux and s390-linux |
# 14:51:13 |
y_morin |
(at least that's what they say there: http://gcc.gnu.org/install/configure.html ) |
# 14:52:15 |
mingwandroid |
y_morin: w64-mingw32 too I guess? |
# 14:55:07 |
mingwandroid |
looking at docs for --with-multilib-list=list, seems that it will select all possible for the target if this option isn't specified, so that's easier for me. |
# 14:55:32 |
mingwandroid |
y_morin: I probably will try and armv8 build on gcc 4.9 to see what pops out anyway. |
# 15:00:25 |
perr |
joins #crosstool-ng |
# 15:13:48 |
mingwandroid |
y_morin: do linaro push back changes to you? |
# 15:48:15 |
perr |
quits : Quit: Leaving |
# 17:35:25 |
mingwandroid |
y_morin: what's the best way to flatten a range of commits into a single patch so I can apply to diorcety branch? |
# 17:47:55 |
y_morin |
mingwandroid: sorry, I was away (cleaning up the house). |
# 17:48:13 |
y_morin |
mingwandroid: If using MQ, then qfold is your friend. |
# 17:48:42 |
y_morin |
mingwandroid: As for Linaro, then pushed back a few stuff, but not much. Plus, they are stuck on crosstool-NG 1.13.0, which is really old, now. |
# 17:49:44 |
y_morin |
s/then/they/ |
# 17:50:43 |
y_morin |
mingwandroid: --with-multilib-list=list does not work for me. It just tries to configure gcc. |
# 18:01:00 |
diorcety |
joins #crosstool-ng |
# 18:05:53 |
mingwandroid |
y_morin: ok thanks. |
# 18:06:02 |
mingwandroid |
y_morin: I started to merge by hand :-) |
# 18:06:56 |
mingwandroid |
y_morin: semi-manually: http://stackoverflow.com/questions/1200691/with-mercurial-how-can-i-compress-a-series-of-changesets-into-one-before-push/1204192#1204192 |
# 18:06:58 |
mingwandroid |
diorcety: hey |
# 18:15:06 |
diorcety |
mingwandroid: hey |
# 18:15:30 |
mingwandroid |
I'm merging our branch with latest from mercurial ATM. |
# 18:15:50 |
diorcety |
mingwandroid: ok great |
# 18:16:18 |
mingwandroid |
diorcety: I will do it to a branch and push to github, then test that a good bit and merge finally. |
# 22:02:10 |
ansiwen |
quits : Remote host closed the connection |
# 22:09:31 |
ansiwen |
joins #crosstool-ng |
# 22:13:53 |
bel3atar |
joins #crosstool-ng |
# 22:14:28 |
bel3atar |
hi I'm getting this in my log : |
# 22:14:31 |
bel3atar |
[CFG ] checking for autoconf... autoconf |
# 22:14:33 |
bel3atar |
[CFG ] checking whether autoconf works... no |
# 22:17:33 |
y_morin |
bel3atar: What does "autoconf --version" returns? |
# 22:18:06 |
bel3atar |
autoconf (GNU Autoconf) 2.69 |
# 22:18:12 |
bel3atar |
y_morin: ^ |
# 22:23:10 |
y_morin |
bel3atar: Hmmm... What else is there in your build.log ? |
# 22:25:36 |
bhundven |
bel3atar: post the log, I know what that is, and it's just a warning. |
# 22:25:49 |
bel3atar |
It's huge |
# 22:25:52 |
bhundven |
there is something else after that. |
# 22:25:55 |
bel3atar |
I don't know where to cut it |
# 22:26:01 |
bel3atar |
ok after |
# 22:26:41 |
bhundven |
(it's why I like the show warnings from tools option) |
# 22:27:03 |
bel3atar |
http://ix.io/apU |
# 22:27:39 |
bhundven |
ok... before that? |
# 22:28:04 |
bhundven |
oh, that's 1.19.0 |
# 22:28:30 |
y_morin |
bel3atar: What does 'make --version' returns? |
# 22:28:43 |
bel3atar |
GNU Make 4.0 |
# 22:28:48 |
bhundven |
^^ |
# 22:29:23 |
bhundven |
don't think we have 4.0 fixed |
# 22:29:35 |
y_morin |
DAH!! make-4.0. Kill, kill, kill! ... :-( |
# 22:29:42 |
bhundven |
you could enable make in the compainon tools |
# 22:29:43 |
y_morin |
Exterminate! |
# 22:29:55 |
bhundven |
at the bottom of menuconfig |
# 22:30:01 |
y_morin |
bel3atar: As bhundven said. |
# 22:30:06 |
bel3atar |
what's wrong with 4.0? |
# 22:30:06 |
bhundven |
3.8.1. |
# 22:30:09 |
bhundven |
*3.81 |
# 22:30:12 |
y_morin |
:-) |
# 22:30:14 |
bhundven |
bel3atar: it's new |
# 22:31:01 |
y_morin |
bel3atar: The problem with make-4.0 is that older tools did not bother to test the major version of make, and only checked for '==3', not '>=3', so they believe it is too old. |
# 22:31:02 |
bhundven |
I <3 3.81, but I still don't understand the splitting of terms 3.82 did. |
# 22:31:24 |
bel3atar |
*** READ HELP before you say 'Y' below !!! *** |
# 22:31:29 |
bel3atar |
[ ] Build some companion tool |
# 22:31:39 |
y_morin |
bhundven: make-3.82 was a real A55H0l3... |
# 22:31:39 |
bhundven |
yes. bryan approved |
# 22:31:46 |
y_morin |
bel3atar: +1 |
# 22:32:09 |
y_morin |
bel3atar: Yet, you should read the help, it's really intructive (I know, I wrote most of it! :-) ) |
# 22:32:32 |
bhundven |
:) |
# 22:32:36 |
bhundven |
rif |
# 22:32:52 |
bel3atar |
Crosstool-NG relies on some external tools to be recent enough... |
# 22:33:47 |
bel3atar |
should I go with make only or with all of the other tools? |
# 22:33:59 |
bhundven |
y_morin: fixing 4.0 should just be a sed statement |
# 22:34:03 |
y_morin |
bel3atar: That's not only about crosstool-NG; it's the components (gcc, blibc, binutils...) that have a wicked check. |
# 22:34:07 |
bhundven |
well, a few of them. |
# 22:34:17 |
y_morin |
bel3atar: While at it, build all of them. They are knopwn to work. |
# 22:34:28 |
bel3atar |
ok thanks |
# 22:34:43 |
y_morin |
bhundven: Yes, of course, not all of them are broken; some are, some are not. |
# 22:36:04 |
bhundven |
CT_LOG_SEE_TOOLS_WARN is what I was talking about earlier. |
# 22:37:23 |
bhundven |
just got done reading fosdem buildroot report |
# 22:38:03 |
bhundven |
does someone just need to get in charge of versioncontrol and release mangement? |
# 22:38:08 |
bhundven |
for uclibc? |
# 22:38:43 |
bhundven |
obviously, if that were happening, contributors would be doing their stuff. |
# 22:39:00 |
bhundven |
iow, fork? |
# 22:39:21 |
y_morin |
bhundven: there is currently someone in charge. It's just that they are really *slow* to put out releases... |
# 22:39:41 |
y_morin |
bhundven: Forking is not really an option either, unless the fork gains momentum. |
# 22:39:44 |
bhundven |
oh, so it's not "dead" |
# 22:40:11 |
y_morin |
bhundven: And these days, uClibc does not make much sense for embedded, except for the exotic architexctures that do not have an MMU. |
# 22:40:48 |
y_morin |
bhundven: Basically, it's on end-of-life, I'm afraid. |
# 22:41:08 |
bhundven |
newlib/bionic :D |
# 22:41:11 |
y_morin |
bhundven: But if you want to put worth some effort toward a last release, then all the power to you! ;-) |
# 22:41:21 |
bhundven |
no, I was just curious |
# 22:41:31 |
y_morin |
bhundven: bionic is not POSIX compliant wrt threads (at least). |
# 22:41:35 |
bhundven |
yea |
# 22:41:48 |
loide |
joins #crosstool-ng |
# 22:42:15 |
y_morin |
bhundven: And the only fitting place nowadays for uClibc are ARC, blackfin and such, for which there is no, and will never be, support in glibc, since they do not have an MMU. |
# 22:42:29 |
y_morin |
And musl (AFAIK) also requires an MMU... |
# 22:42:54 |
loide |
quits : Client Quit |
# 23:34:54 |
y_morin |
quits : Quit: Nighty Night! |
# 23:38:09 |
smartin_ |
quits : Quit: leaving |